Dynamic Menus for Multi-Prefix Interactive Mobile Searches

ABSTRACT

The present invention includes systems and methods for retrieving information via a flexible and consistent targeted search model that employs interactive multi-prefix, multi-tier and dynamic menu information retrieval techniques that provide context-specific functionality tailored to particular information channels, as well as to records within or across such channels, and other known state information. Users are presented with a consistent search interface among multiple tiers across and within a large domain of information sources, and need not learn different or special search syntax. A thin-client server-controlled architecture enables users of resource-constrained mobile communications devices to locate targeted information more quickly by entering fewer keystrokes and performing fewer query iterations and web page refreshes, which in turn reduces required network bandwidth.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/563,669 entitled “Dynamic Menus for Multi-Prefix Interactive MobileSearches,” filed Jul. 31, 2012; which in turn claims the benefit of U.S.patent application Ser. No. 12/142,725 entitled “Dynamic Menus forMulti-Prefix Interactive Mobile Searches,” filed Jun. 19, 2008 andissued as U.S. Pat. No. 8,255,382; Provisional Patent Application No.61/048,073 entitled “Multi-Tier Desktop Search,” filed Apr. 25, 2008;Provisional Patent Application No. 60/947,099 entitled “Dynamic MenuFeature,” filed Jun. 29, 2007; and Provisional Patent Application No.60/945,300 entitled “Dynamic Menu Feature” filed Jun. 20, 2007. Thisapplication also claims priority to U.S. patent application Ser. No.12/620,195 entitled “Dynamic Menus for Multi-Prefix Interactive MobileSearches.” filed Nov. 17, 2009 and issued as U.S. Pat. No. 8,255,411,which in turn claims the benefit of U.S. Provisional Patent ApplicationNo. 61/115,665 entitled “Smart PreFix Query Optimization,” filed Nov.18, 2008; U.S. Provisional Patent Application No. 61/149,281 entitled“Smart Prefix Query Optimization,” filed Feb. 2, 2009; and U.S.Provisional Patent Application No. 61/247,440 entitled “Building andSharing Apps Using Collaborative Services,” filed Sep. 30, 2009. Each ofthe patent applications cited herein are incorporated herein byreference in their entireties.

BACKGROUND

1. Field of Art

This application relates generally to the field of information retrievaland, in particular, to multi-prefix, multi-tier, dynamic menu andrelated interactive search techniques that facilitate the retrieval ofinformation within a mobile communications environment.

2. Description of Related Art

In the last few years, web-enabled mobile telephones have becomeenormously popular. More web-enabled mobile phones ship each year thando desktop and notebook computers combined. Such mobile phones aresimilar to desktop and mobile computers in that they offer displayscreens, a keyboard, and, sometimes, a pointing device. However, becauseof portability requirements, the capabilities of the displays,keyboards, and pointers on mobile phones are significantly reduced.Displays are relatively small with little area to display content aswell as menus, toolbars, and other navigation and status information.The keyboards are often telephone keypads or thumb keyboards. Thepointer, when provided, is often a scroll wheel or joystick that can beused to indicate a direction of movement or pressed to indicate a click.Sometimes, the pointer is simply a set of arrow keys on the keyboard.Furthermore, because of speed and latency issues, navigation among webpages is typically much slower on mobile phones than on desktop andnotebook computers.

The human interface limitations of mobile phones, combined with slowernavigation, significantly constrain a user's ability to interact withweb pages. Additionally, Hypertext Markup Language (HTML) forms aredifficult to use on mobile phones due to data input and relatedlimitations. These difficulties arise in many ways. For example, themobile keyboard and pointer are less effective than their counterpartson desktop and personal computers.

Keyboards are less effective because their small form factor makes itmore difficult to type characters. In some case, the keyboard is smallerand has fewer keys. The smaller keyboards usually require thumbing:typing with one's thumbs rather than using ten fingers. The reduction inkeys makes it more difficult to key in digits and special characters.Some keyboards are telephone dial pads with multiple letters on eachkey. Various technologies, including triple tap (pressing the same keyuntil the desired letter appears) and predictive text, help to improvethe effectiveness of such keyboards, but the effectiveness is still farbelow that of a full-size keyboard.

The pointer is also less effective. HTML forms often contain multipleinput fields and the pointer is used to navigate among them. Pointers onmobile phones, when available, are less effective than pointers or miceused with desktop computers for navigating among input fields, as wellas hyperlinks and other screen objects. For example, tabbing betweenfields using a full-size keyboard enables the field for typing when ithas received focus. On a mobile phone, the tabbing is typically done viaa directional pad and the field often has to subsequently be selected tobe enabled for typing. Additionally, on desktop computers, mice can beused to move from one field to another without having to move throughthe fields in between. On mobile phones, moving from one field toanother is typically done sequentially from one field to the next,without the ability to skip any fields along the way.

However, some web-enabled mobile phones have touchscreens that providefor direct interaction with objects on the display screen. For example,users can touch a screen object directly with their fingertip or astylus, rather than indirectly navigate to that object via a pointingdevice. Yet, even this “improved” user interface technique raisesusability issues, as the distinction between “selecting” and“activating” an object becomes blurred. Potential solutions fordistinguishing the two include providing an icon or other visibleidentifier on a portion of the object, or discerning the number of timesa user clicks or taps it, or the amount of time a user “presses down” onthe object.

In any event, the ability to select an object without also activating itbecomes particularly important in systems that provide alternativefunctionality specific to a particular object. For example, when a useractivates an HTML hyperlink in a web browser, the program typicallynavigates to a new web page corresponding to the URL embedded withinthat hyperlink object. The user, however, might want to examine the URLbefore making the decision to activate the hyperlink.

A common mechanism for offering a user alternative functionalityspecific to a selected object is a “context menu.” Context menus providea user with one or more alternative functions available within aparticular “context” or state of a program or device, such as theselection of a particular object. Context menu items can changedynamically as the context changes, as different objects are selectedand as a program enters a different state.

In a mobile communications environment, however, providing context menuswith which users can quickly interact is easier said than done. Thestate of an information retrieval system can change frequently, forexample, as new search results are received from remote servers (or asinformation becomes known to the system, such as the time of day or auser's location as indicated by a mobile phone's GPS equipment). Inaddition to the problem noted above of distinguishing the selection fromthe activation of an object, other constraints include processing speedand memory limitations on mobile devices, as well as bandwidth andlatency limitations inherent in mobile communications networks. Theseconstraints, coupled with the many different types of information thatcan be retrieved from remote web sites, for example, make it even moredifficult to provide context menu items that are customized toparticular objects or categories of objects.

In contrast to the “random” full-text searches users often perform ondesktop computers in home and office environments (in which multipleiterative searches and analyses of resulting web pages can be completedrelatively quickly due to greater bandwidth and local computingresources), users in a mobile communications environment often performmore “targeted” searches for lists, schedules and other information theexistence and perhaps even the location of which is often known inadvance. Such information must nevertheless be retrieved relativelyquickly in order to be useful. For example, common mobile searchesinclude requests for stock quotes, sports scores, movie times and nearbyrestaurants or coffee shops, to name a few.

Targeted searches are less amenable to the random keyword searchtechniques commonly employed on existing desktop and mobile devices, inwhich users enter complete keywords and navigate through results and webpages across a large domain of web sites. Mobile devices, in particular,are in need of solutions in which targeted information can be foundrelatively quickly with minimal user interaction. Such solutions ideallywould still afford users access to both the breadth of a large domain ofinformation (such as the web with its diverse collection of web sites,or a large enterprise database) and the depth of any particular“channel” or information category (which may lend itself to uniquefunctionality, whether within or across one or more web sites ordatabases).

Some mobile devices support applications that have been customized forhighly targeted information retrieval, such as the “Pocket Express”application from Handmark Inc. (http://express.handmark.com/) whichprovides discrete modules for retrieving news, stock quotes, sportsscores and various other specific types of information. Though usefulfor rapid retrieval of certain specific data, the domain of availableinformation is inherently very limited, in part because each desiredcategory of information requires its own custom module. Such an approachis not very scalable, given the vast array of information channelsavailable via the web. Moreover, without a generic mechanism to locateinformation by searching within a particular module, users typically arelimited to browsing or selecting items from within each module'spredefined data structure. For example, users can browse news headlinesand select one to retrieve the full story, but they cannot search forparticular news stories, much less headlines.

Other products have attempted to reduce user interaction to performtargeted searches by enabling users to enter only word prefixes or wordfragments, and providing results interactively as a user typescharacters. See, for example, a presentation at Google(http://video.google.com/videoplay?docid=7012265262667474421&qtype%3Agoogle+engEDU)in this area, or the “vTap” program from Veveo, Inc.(http://www.vtap.com), as well as Veveo's various published patentapplications, including both PCT publications (WO/2007/062035) and USpublications (2008011473, 20080086704, 20070255693, 20070130128,20070088681, 200701754, 20070050337, 20070005563 and 20060101499). Whileproviding an information retrieval mechanism that is more suitable totargeted searches, such approaches nevertheless lack a generic searchmechanism that can be utilized to narrow a search request within a broaddomain of information channels (to provide a more focused or targetedsearch), as well as provide additional functionality specific toparticular channels.

Google, in a recent talk (http://jhtc.org/meeting.php?meeting=march08),discussed a “multi-tier” search technique in which a user first searchesfor a web site (for example, “Wikipedia”), the result of which containsnot only a link to that site, but also a search box in which a“second-tier” search can be typed (thus saving the step of clicking onthe link and then typing in the second-tier search). Other similarsolutions include special search keywords that identify the second-tiersite within the search query itself. Such solutions rely, however, onthe differing search engines available across various second-tier sites,which not only force users to adapt to different search query formats,but also may provide inferior results when compared to more powerfulsearch engines such as the one provided by Google. A more integratedmulti-tier approach could avoid such anomalies by providing a consistentsearch mechanism among various tiers (within as well as acrossparticular information channels), particularly one which also offeredadditional context-specific functionality.

In short, existing technologies have not adequately addressed theproblems intrinsic to targeted searches, particularly when conducted ina mobile communications environment. Information must be retrieved morequickly, but with less user interaction, in light of the hardware, userinterface, network bandwidth and latency limitations inherent in such anenvironment. In addition, a more integrated and scalable searchmechanism is needed to allow users to request information from a broaddomain of information channels and quickly locate desired informationwithin one or more of those channels, preferably with the availabilityof additional functionality that is tailored to those channels withinthe context of user requests and other available state information.

SUMMARY

The present invention addresses the problems discussed above byemploying novel combinations of various information retrieval techniquesdesigned to facilitate targeted searches, particularly in a mobilecommunications environment. In one embodiment, multi-prefix searchtechniques are employed in an effort to minimize a user's data entryrequirements. Moreover, user queries can be executed on a remote serverinteractively, during the query construction process, with resultstransmitted back for display so as to enable users, prior to entering anentire query, to revise that query or select a desired result.

To facilitate targeted searches, users can employ multi-tier searchtechniques to constrain queries to one or more information channels. Inone embodiment, users can simply select one or more channels from alist, which could include previously designated “favorite” channels. Inanother embodiment, users can employ multi-prefix searches to locatedesired channels as well as desired information within particularchannels (and, in some cases, within multiple tiers of one or more suchchannels).

For example, after locating a “yellow pages” channel with a “first-tier”search (such as “yel pag”), the user might be presented with a“second-tier” opportunity to search for “zip codes.” After entering onlya few digits, the user might see the desired zip code result displayedand, upon selecting it, be presented with a “third-tier” opportunity tosearch for a vendor within that selected zip code. Such a multi-tierapproach facilitates targeted mobile searches by reducing userinteraction and data entry, and, in another embodiment, by leveraging aconsistent multi-prefix search mechanism among multiple tiers.

In one embodiment, a mobile communications device includes a window,which comprises a search area and a results area. An application islaunched and a landing page is displayed in a display area of the mobilecommunications device. The search area includes a search query field. Akeystroke is inputted into a search query field and a multi-prefixsearch is performed. The landing page within the display area isreplaced by the results of the search. The results contain a first tierof search results, which can include channels or links to web pagesassociated with the user input. If the selected search result is achannel, the channel is displayed. If it is a web page, the web page isdisplayed. In other embodiments, a separate web browser application islaunched and the web page is displayed via the web browser application.The channel or the web page may then be searched or explored. If thedesired channel is not displayed within the first tier of searchresults, one or more additional keystrokes may be inputted. Again, theresults page refreshes accordingly and additional keystrokes may beentered until the desired channel is displayed.

The above-described embodiments provide for multi-prefix, interactivesearch capability on a mobile communications device. Prefix delimitersdenote the beginning of another search prefix. In some embodiments,space characters may be used as prefix delimiters. In other embodiments,users may input space character keystrokes as well as alphabetic ornumeric keystrokes. If a user's query seeks results containing multiplewords, the user might enter one or more prefixes of such words separatedby spaces to create a multi-prefix search query. The embodimentsdescribed above enable users to enter fewer keystrokes to obtain adesired search result. The search is interactive because a user isprovided feedback (the displayed search results are refreshed) with eachkeystroke (or, in another embodiment, after a predefined time lapsebetween keystrokes). Based on partial query results, a user candetermine that a search is complete and obtain the desired search resultwithout having to enter the entire text or word of one or more searchterms.

To further leverage targeted searches, in which search results oftenshare common attributes (including similar types of fields and dataformats), the data extracted from an information channel (from a givenweb site, for example, or a portion thereof) can, in one embodiment, bepre-processed for functional as well as aesthetic display purposes.Whether captured as keywords via a “web crawling” engine, or asstructured data via higher-level data extraction techniques (with orwithout the assistance of the proprietor of the data), such channel datatypically is or can be organized into separate “records” (such asindividual restaurants, books or movies) containing discrete “fields”that represent different types of data (such as titles, dates, addressesand phone numbers) common to some or all records. This is primarily dueto the fact that most web sites employ databases (typically standardrelational, flat-file or object-oriented databases) as the underlyingorganizational structure for their data.

In one embodiment, channel data records and fields can be indexed assuch in order to enable structured searches based upon these records andfields. In another embodiment, the indexing process ignores data fielddistinctions but is optimized for multi-prefix searches. The frequencyof extracting data from remote information sources (whether for indexingor otherwise) will vary depending upon how frequently such datatypically will be updated. For example, sports scores may be updatedmore frequently than movie listings, which in turn may be updated morefrequently than restaurant listings. Whether or not field (or other)metadata is retained during the indexing process (if any), the channeldata still may be susceptible to “field recognition” sufficient toenable the performance of discrete actions specific to a particularfield. For example, if standard ten-digit phone numbers can be extractedfrom individual channel data records, such as restaurants, then suchextracted data can be used to enable actions specific to a particularrecord, such as using a mobile phone device to call one of therestaurants displayed in the result list of a user's query.

Having extracted and maintained field data related to one or morechannels (or even to particular records within one or more channels),various contextual actions can be enabled as alternatives to simplyselecting and activating a particular record (which might activate ahyperlink to a web page related to that record). In one embodiment,“dynamic menus” are employed to enable a wide variety of alternativeactions specific to a selected record, including calling a person or aplace, sending a selected person an email, SMS or other type of message,utilizing a known location (of a user's mobile device, for example, viaGPS data, or of a particular place in the result list of a user's query)to view the location of, or directions to, nearby places, or to obtain amap of a desired area, or even linking to a web page related to aparticular aspect of a record (to display, for example, images of aselected person). The possibilities are virtually limitless, as they mayinvolve not only actions of which a mobile communications device iscapable (such as initiating phone calls and sending messages), but alsoactions relating to the channel data being retrieved, which are asnumerous as the many different types of information available throughoutthe Internet.

This relationship, between different fields or types of available dataand the actions that relate to such data, can be leveraged, even in amobile communications environment, not only by pre-processing thechannel data itself, but by pre-defining the related actions specific tothat channel data (with or without the assistance of the proprietor ofthe channel data) and transmitting them, in response to user queries,along with the channel data query results. In one embodiment, theseactions are transmitted to a user's mobile device in the form ofHypertext Transfer Protocol (“HTTP”) headers that define both the nameof a dynamic menu item and the action to be taken if the user selectsand/or activates that item (and are followed by the “body” of thetransmission including, for example, the results of a user's query). Inanother embodiment, if the functionality of the client application onthe user's mobile device is integrated into a web browser (using, forexample, Javascript and an Ajax application), then these HTTP headerscan be incorporated into the body of the transmission itself.

For example, if a user employs a multi-prefix query to search a channelcontaining a collection of restaurant records, the server might return aseries of HTTP headers (followed by the resulting restaurant recordsmatching the user's query) representing dynamic menu items that enablethe user to initiate a call to a selected restaurant, or obtain a mapand directions to that restaurant from a given location. Yet, if thatuser queried a different channel containing, for example, a collectionof movie records, then the HTTP headers delivered with the results ofthe user's query might represent a different set of dynamic menu itemsproviding actions such as displaying movie reviews, or playing videotrailers.

In other embodiments, these dynamic menu items and their associatedactions might vary depending not only upon the channel being queried,but upon the particular channel records the user selects. For example,in one embodiment, if a selected record did not contain a value for aparticular field (such as a phone number), then any correspondingdynamic menu item relating to that field (such as a “Call Restaurant”item) would not appear, because the action could not be performed. Moregeneric “dynamic dynamic menus” can be implemented, in anotherembodiment, by integrating menu item names and associated actions asdiscrete data fields within one or more channel records. As a result,menu item names and actions will vary as a user selects differentrecords, even within a given channel. In yet another embodiment, certainactions, such as dialing a selected restaurant, can be invoked withoutrequiring a user to display, select or activate a dynamic menu item.Instead, a user might simply press a key or push a button on the user'smobile device (such as the “Talk” button) to which such actions havebeen mapped. As noted above, dynamic menu items might also varydepending upon any particular state of a user's query or other knowninformation, such as whether a user has logged into a particular website (in which case a “Log In” menu item and associated action mightalternate with a “Log Out” menu item and action, depending upon theuser's login state).

In other embodiments, information channels can be implemented as a typeof “smart bookmark” in a mobile web browser. After a user selects (orsearches for) one or more channels, the user may perform a “second-tier”search constrained to that channel utilizing, for example, aninteractive multi-prefix query. A mobile search engine can providesimilar functionality, whether or not integrated into a mobile webbrowser. Such functionality can be enabled, in one embodiment, bypre-processing channel data as described above at a remote server fromwhich search results are transmitted. Moreover, dynamic menus can beimplemented in a manner similar to that described above by transmittingmenu items and associated actions along with such interactive searchresults. In yet another embodiment, such functionality can beimplemented as a standalone application limited to one or morepredefined channels.

When a consistent targeted search mechanism (such as one that employsthe interactive multi-prefix and multi-tier information retrievaltechniques described above) is coupled with a dynamic menu mechanismthat provides context-specific functionality (tailored, for example, toparticular channels, records within or across those channels, or otherstate information), users are presented with a consistent searchinterface among multiple tiers across and within information channels,and need not learn different or special search syntax. Moreover, due tothe constraints of a mobile communications environment, data entryrequirements are limited, enabling users to enter fewer keystrokes andperform fewer query iterations, which in turn reduces network bandwidthin both directions, due in part to the interactive nature of themulti-prefix search mechanism. As a result, users can obtain desiredresults quickly, or revise queries, even before completing an intendedquery.

For example, a user with a particular preference for Starbucks coffeemight want to locate the closest starbucks coffee shop quickly whiletraveling in an unfamiliar city, and then call that shop to ensure theuser's order is ready upon arrival. Upon entering a few keystrokes intoa mobile phone device, a local yellow pages channel can be located(assuming a “favorite” Starbucks channel was not present) and queriedfor a nearby Starbucks coffee shop, perhaps using the phone's GPS databy default as a base location. Due to a consistent multi-prefix searchinterface, data entry is limited, and channel-specific functionality canthen be invoked. For example, a phone number field, associated with theuser's selected Starbucks record, can then be leveraged via a simplemechanism, such as a phone button or dynamic menu item, to enable theuser to call the desired Starbucks coffee shop and place an order.Another dynamic menu item might provide a map and directions to thatStarbucks, enabling the user to arrive in time to pick up that order.Most importantly, all of this functionality can be provided within thecontext of a highly constrained mobile communications environment.

The features and advantages described in the specification are not allinclusive, and, in particular, many additional features and advantageswill be apparent to one of ordinary skill in the art in view of thedrawings, specification and claims. Moreover, it should be noted thatthe language used in the specification has been principally selected forreadability and instructional purposes, and may not have been selectedto delineate or circumscribe the disclosed subject matter.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1A illustrates an environment adapted to support multi-prefix,interactive searching on a mobile communications device in accordancewith some embodiments.

FIG. 1B is a high level block diagram illustrating the data structurecontained within the channel database in accordance with someembodiments.

FIG. 2 is a high level block diagram illustrating a functional view of atypical mobile communications device in accordance with someembodiments.

FIG. 3A is a flowchart illustrating a process of client-serverinteraction during multi-prefix, interactive searching in accordancewith some embodiments.

FIG. 3B is a flowchart illustrating a process of client-serverinteraction during multi-prefix, interactive searching in accordancewith some other embodiments.

FIG. 3C is a flowchart illustrating a process of client-serverinteraction during multi-prefix, interactive searching in accordancewith some other embodiments.

FIG. 4 is a flowchart illustrating a process for interactive searchingin accordance with some embodiments.

FIG. 5 is a flowchart illustrating a process for creating a multi-termprefix index in accordance with some embodiments.

FIG. 6 is a flowchart illustrating a process for creating a table ofcontents in accordance with some embodiments.

FIG. 7 is a flowchart illustrating a process for sending interactivesearch results in accordance with some embodiments.

FIG. 8 is a flowchart illustrating a process for sending interactivesearch results in accordance with some embodiments.

FIGS. 9A-9M illustrate graphical representations of screenshots of adisplay of a mobile communications device in accordance with someembodiments.

FIGS. 10A-10C illustrate graphical representations of screenshots of adisplay of a mobile communications device in accordance with anotherembodiment.

FIGS. 11A-11C illustrate graphical representations of screenshots of adisplay of a mobile communications device in accordance with anembodiment of the dynamic menu aspect of the present invention.

FIGS. 12A-12G illustrate graphical representations of screenshots of adisplay of a mobile communications device in accordance with anotherembodiment of the dynamic menu aspect of the present invention.

The figures depict various embodiments of the present invention forpurposes of illustration only. One skilled in the art will readilyrecognize from the following discussion that alternative embodiments ofthe structures and methods illustrated herein may be employed withoutdeparting from the principles of the invention described herein.

DETAILED DESCRIPTION

The Figures (FIGS.) and the following description relate to preferredembodiments by way of illustration only. It should be noted from thefollowing discussion that alternative embodiments of the structures andmethods disclosed herein will be readily recognized as viablealternatives that may be employed without departing from the principlesof what is claimed.

Reference will now be made in detail to several embodiments, examples ofwhich are illustrated in the accompanying figures. It is noted thatwherever practicable similar or like reference numbers may be used inthe figures and may indicate similar or like functionality. The figuresdepict embodiments of the disclosed system (or method) for purposes ofillustration only. One skilled in the art will readily recognize fromthe following description that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles described herein.

I. Search Architecture

FIG. 1A is a block diagram illustrating an architecture for providingmulti-prefix, interactive search capability on a mobile communicationsdevice. The network 122 enables communications between a client 118 anda search server 128 coupled to a data store 112. Thus, the network 122can include links using technologies such as Wi-Fi, Wi-Max, 2G,Universal Mobile Telecommunications System (UMTS), 3G, Ethernet, 802.11,integrated services digital network (ISDN), digital subscriber line(DSL), asynchronous transfer mode (ATM), InfiniBand, PCI ExpressAdvanced Switching, etc. Similarly, the networking protocols used on thenetwork 122 can include the transmission control protocol/Internetprotocol (TCP/IP), multi-protocol label switching (MPLS), the UserDatagram Protocol (UDP), the hypertext transport protocol (HTTP), thesimple mail transfer protocol (SMTP), the file transfer protocol (FTP),lightweight directory access protocol (LDAP), Code Division MultipleAccess (CDMA), Wideband Code Division Multiple Access (WCDMA), GlobalSystem for Mobile communications (GSM), High-Speed Downlink PacketAccess (HSDPA), etc. The data exchanged over the network 122 can berepresented using technologies and/or formats including the hypertextmarkup language (HTML), the extensible markup language (XML), etc. Inaddition, all or some of links can be encrypted using conventionalencryption technologies such as the secure sockets layer (SSL), SecureHTTP and/or virtual private networks (VPNs) or Internet Protocolsecurity (IPsec). In another embodiment, the entities can use customand/or dedicated data communications technologies instead of, or inaddition to, the ones described above. Depending upon the embodiment,the network 122 can also include links to other networks such as theInternet.

The client 118 executes a browser 120, comprises client applications 124and can connect to the search server 128 via a network 122, which istypically the Internet, but may also be any network, including but notlimited to a LAN, a MAN, a WAN, a mobile, wired or wireless network, aprivate network, or a virtual private network, and any combinationthereof. While only a single client 118 is shown, it is understood thatvery large numbers (e.g., millions) of clients are supported and can bein communication with the search server 128 and search result updatemodule 116 at any time. The client 118 may be a mobile communicationsdevice similar to the one described in FIG. 2.

The search server 128 includes a search result update module 116, amulti-prefix search module 150, a multi-tier search module 152, and aresult delivery search module 154. The search server 128 facilitatesmulti-prefix, multi-tier, interactive searching by enabling a user toenter prefixes of words or text of a search query to obtain various tierlevels of search results. The search server 128 also facilitatesmulti-prefix, interactive, result delivery searching by enabling a userto enter prefixes of words or text to obtain desired results withouthaving to go through intermediary steps to get those results. The searchserver 128 also facilitates multi-prefix searching on a mobilecommunications device.

The search result update module 116 facilitates the update of the searchresults when a user inputs a keystroke (or pauses for a certain amountof time after entering multiple keystrokes), therefore allowing forinteractive search capability. Multi-prefix search module 150facilitates multi-prefix searching by providing the user the ability toenter the prefix of one or more words of an entire query to obtaindesired search results. The multi-tier search module 152 facilitatesmulti-tier searching by providing different tier levels of results. Theresult delivery search module 154 facilitates result delivery bysearching a plurality of data fields associated with a particular dataset in order to produce desired results. Further description regardingusage of these modules is provided below.

The search server 128 is coupled to a data store 112. The data store 112includes a channel database 114, an index database 130 and a table ofcontents database 132. A channel represents a content category, such asnews, flight information, recipes, etc. The channel database 114contains records. Each record contains a heading and one or more URLs.The record also contains an indication as to whether each URL referencesa channel. Then index database 130 contains lists of prefixes and, foreach prefix, a list of record IDs that contain words with the prefix, aswell as relevancy factors for use in ranking. The table of contentsdatabase 132 contains prefix entries to aid in traversing the index. Thenumber of entries contained in the table of contents database 132affects the time spent traversing the index to find relevant record IDlists. A greater number of entries in the table of contents will slowdown the search of the table of contents database 132, but reduce thetime spent traversing the index to find relevant record ID lists. Fewerentries contained in the table of contents database 132 will speed upthe search of the table of contents, but increase the time spenttraversing the index to find relevant record ID lists. Furtherdescription regarding usage of these modules is provided below.

As illustrated in FIG. 1B, the channel database 114 includes channeldata sets 140. Each channel data set 140 includes a list of records 142.Each record contains data fields 144. Each record is associated with atleast one heading and a “deep link” (a hypertext link to a page or a website other than its home page). In some embodiments, each recordcontains a heading and a parameter that can be inserted into a URLtemplate to create a deep link. A heading may be the displayed titleassociated with a particular record. For example, in a list of Wikipediaarticles, an example of a heading may be “John Fitzgerald Kennedy,”“High School Musical,” or “World Wide Web.” Headings in a directory ofpeople might include a person's name, telephone number or address.

Each data field 144 contains identifying information related to thatparticular channel. A data field 144 may also contain other informationrelated to that particular channel. For example, in an AMAZON™ Bookschannel, the data fields 144 may contain items such as a title, anauthor, an International Standard Book Number (ISBN) and a price. In aWhite Pages channel, the data fields 144 may contain a name, an address,a home phone number and a mobile phone number. In some embodiments, onedata field 144 contains multiple items. In other embodiments, each datafield 144 contains separate items.

In some embodiments, a data field 144 may be associated with additionalitems that represent terms that are equivalent to the original itemscontained in the data field. For example, in a name data fieldcontaining “Robert,” that data field may be associated with terms suchas “Bob,” “Bobby” or “Rob” (i.e. terms that are equivalent to the term“Robert”).

Those skilled in the art will recognize that the search server 128 isimplemented as a server program executed on a desktop computer, laptopcomputer, or server-class computer comprising a CPU, memory, networkinterface, peripheral interfaces and other well known components. Thecomputers themselves preferably run an open-source operating system suchas LINUX, have generally high performance CPUs, 1 G or more of memory,and 100 G or more of disk storage. Of course, other types of computerscan be used, and it is expected that as more powerful computers aredeveloped in the future, they can be configured in accordance with theteachings here. The functionality implemented by any of the elements canbe provided from computer program products that are stored in tangiblecomputer accessible storage mediums (e.g., RAM, hard disk, oroptical/magnetic media).

For purposes of illustration, FIG. 1A shows the search result updatemodule 116, the multi-prefix search module 150, the multi-tier searchmodule 152, the result delivery search module 154, the channel database114, the index database 130 and the table of contents database 132 asdiscrete modules. However, in various embodiments, any or all of theresult update module 116, the multi-prefix search module 150, themulti-tier search module 152, the result delivery search module 154, thechannel database 114, the index database 130, and the table of contentsdatabase 142 can be combined for operation on a single computing devicehaving storage. This allows a single module to perform the functions ofone or more of the above-described modules. Further, the search server128 and the data store 112 are shown as discrete components for purposesof illustration. In other embodiments, the search server 128 and thedata store 112 can also be combined for operation on a single computingdevice having storage.

FIG. 2 is a high level block diagram illustrating a functional view of atypical mobile communications device 200 in accordance with someembodiments. Illustrated are at least one processor 202 coupled to a bus204. Also coupled to the bus 204 are a memory 206, a storage device 208,a graphics adapter 212, a network adapter, and a mobile transceiver 210including a display, keyboard, and optionally, a pointing device (notshown). In some embodiments, the display is a touchscreen display. Inone embodiment, the functionality of the bus 204 is provided by aninterconnecting chipset.

The storage device 208 is any device capable of storing data, such as amemory stick, a secure digital (SD) card, a solid-state memory device ora hard drive. The memory 206 stores instructions and data used by theprocessor 202. The optional pointing device (not shown) is used incombination with the keyboard (also not shown) to input data into themobile communications device 200. The graphics adapter 212 displaysimages and other information on the display of the mobile communicationsdevice 200. The network adapter 216 couples the mobile communicationsdevice 200 to a local or wide area network.

As is known in the art, a mobile communications device 200 can havedifferent components from those shown in FIG. 2. Furthermore, the mobilecommunications device 200 can lack certain illustrated components orinclude certain components not shown.

As is known in the art, the mobile communications device 200 is adaptedto execute computer program modules for providing functionalitydescribed herein. As used herein, the term “module” refers to computerprogram logic utilized to provide the specified functionality. Thus, amodule can be implemented in hardware, firmware and/or software. In oneembodiment, program modules are stored on the storage device 208, loadedinto the memory 206 and executed by the processor 202. The modules maybe loaded as part of the client applications 124.

Embodiments of the entities described herein can include other and/ordifferent modules than the ones described here. In addition, thefunctionality attributed to the modules can be performed by other ordifferent modules in other embodiments. Moreover, this descriptionoccasionally omits the term “module” for purposes of clarity andconvenience.

II. Search Operation

FIG. 3A is a flowchart illustrating a process 300 of client-serverinteraction during multi-prefix, multi-tier, interactive searching inaccordance with some embodiments. An application for multi-prefix,multi-tier, interactive searching is initialized 301 by a mobilecommunications device. The server sends 302 an initial information todisplay in a window of the mobile communications device. The window isdisplayed 303 on a display of the client device. In one embodiment, thewindow appears like the window 902 as illustrated in FIG. 9A. The window902 includes a search area 903, which includes a search query field 904,and a display area 905. The display area 905 includes a landing page901, which contains headings 906 for associated channels for userselection. Each heading 906 refers to either another channel (list ofheadings) or to a URL, which may be a deep link into a web site. Theheadings 906 are links to categorized information, such as news,celebrity photos or flight status. The headings 906 may also be links tovarious websites, such as gmail.com and fandango.com. A keystrokeassociated with an alphanumeric character is input 304 on the mobilecommunications device in the search query field 904 as shown in FIG. 9A,and sent 304 to the server. The user input is received 306, a search 307of the channel database 114 is performed using the input, and sent 308to the client. The display area 905 is updated accordingly. The displayarea 905 displays 309 a first tier of search results, which includechannels associated with the user input. As shown in FIG. 9B, a userinputs “St” in the search query field 904, and the display area isrefreshed to display results corresponding to the “St” search query. Inthis example, “St” corresponds to search results “STARBUCKS™ StoreLocator,” “FlightView Airline Flight Status” “Stock Quotes,” etc. In oneembodiment, the displayed result, such as shown in FIG. 9B, may alsoinclude other organizational information such as the labels 910(“Popular Channels” or “All Channels”) to provide the user withadditional information such that the headings are intuitively recognizedand understood by the user. The displayed results may also includeselectable links 915 to channels or websites as shown in FIG. 9B.

If the desired result is displayed (310—Yes), a result may be selected312. The result selection is received 314 and the corresponding channelor web page is sent 315 to the client. The channel or web page is thendisplayed 316 on the display of the mobile communications device. Theselection directs the user to the channel or website corresponding tothe selected result where the user can input 318 a search query in thechannel or web page or simply explore 318 the displayed page. In someembodiments, if the result selected is a web page, a separate webbrowser is launched to display the web page. As shown in FIG. 9C, theuser has selected the STARBUCKS™ Store Locator channel 906 (FIG. 9B).This selection directs the user to the STARBUCKS™ Coffee Store Locatorchannel as shown in FIG. 9C.

If the desired result is not displayed (310—No) within the searchresults, another keystroke may be inputted 304. Again, the user input isreceived 306, the channel database 114 is searched 307, results are sent308, and the display area is refreshed accordingly by displaying 309 thesearch results. Additional keystrokes may be entered until the desiredchannel is displayed. With each keystroke, the results list is updatedby the search result update module 116.

In some other embodiments, users may input space character keystrokes aswell as alphabetic or numeric character keystrokes. As shown in FIGS. 9Eand 9F, a user has selected the Starbucks Coffee Locator channel and hasentered a search query in the search query field 904 that includes aprefix delimiter, such as a space character. The user's search entry inthe search query field 904 represents the prefixes for each word of amulti-prefix search query. The user has entered a first prefix (firstletter or first several letters of a word or text), separated by a spacecharacter, and a second prefix, and is provided with a list of searchresults corresponding to the user input by the multi-prefix searchmodule 150. This allows users to input fewer keystrokes to obtain thedesired search results. In other embodiments, a wild card character or asymbol can be used in place of spaces between multiple prefixes of asearch.

The method described above provides for a multi-prefix, interactivesearch capability. The search is multi-prefix because if the search termcontains multiple words, the user enters the prefix of one or more wordsof the multi-term search query, therefore, providing the capability forusers to enter less keystrokes and obtain a desired search result. Thesearch is interactive because a user is provided feedback (displayedsearch results) with each keystroke. Based on partial query results, auser can determine when the search is complete and can obtain thedesired search result without having to enter the entire search term.Therefore, fewer keystrokes are needed as compared to searching usingthe current technologies available.

FIG. 3B is a flowchart illustrating a process 320 of client-serverinteraction during multi-prefix, interactive searching in accordancewith another embodiment. A channel or web page is sent 315 to theclient. The window, including a search area and a display area, of thechannel or web page is then displayed 316 on the display of the mobilecommunications device. In one embodiment, the window may look like thewindow 920 as illustrated in FIG. 9C or 9I. The search area 921 includesa search query field 924. A user inputs 324 keystrokes in the searchquery field 924. The server receives 326 the user input and searches 328the data fields of the records in the channel for search results thatmatch the search query. For example, if the White Pages channel wasbeing searched, the server would receive the search query and search thename, address, and telephone number fields of the records to determineif there was a match for the received search query. The result list isthen sent 329 to the mobile communications device.

Search results 926 that match the search query are displayed 330 in thedisplay area 933 as shown in FIG. 9D. In some embodiments, as shown inFIG. 90, additional information 925 associated with the search result isdisplayed in the display area 933 along with the search result 926. Ifthe desired result in the list of results 926 is displayed (332—Yes),then the desired result may be selected 334 and additional informationabout the result may be displayed. However, if the desired result is notdisplayed in the list of results (332—No), another keystroke may beinputted 324 to receive and display different search results. Spacecharacter keystrokes may also be inputted to indicate that the searchquery has multiple terms.

When the server 128 searches for a search result that matches the searchquery, the server searches the various data fields and records within achannel data set. In one embodiment, the search is performed onstructured data, such as the data set described in the channel database114. In other embodiments, the search is performed on unstructured data,which includes data and links without categorized fields.

FIGS. 9C-9G provide an illustration of the method. In FIG. 9C, thewindow 920 for the STARBUCKS™ Coffee Locator includes a search area 921and display area 933. The search area 921 includes a search query field924. The display area 933 in FIG. 9C shows an initial landing page 931.In some embodiments, the landing page 931 may also include selectablelinks 932 to additional information. Keystrokes, which includealphanumeric characters, are entered into the search query field 924 asseen in FIG. 9D. Search results 926 are displayed in the display area933 as shown in FIG. 9D. Additional keystrokes are entered into thesearch query field 924 (FIGS. 9E and 9F) to input a second prefix, andthe search results list 926 is refreshed with search results that matchthe updated search query having two prefixes. In the illustrationsprovided in FIGS. 9E and 9F, the prefix of a word is entered into thesearch query field 924, followed by a space character and the prefix ofanother word of the search term. A prefix is the first letter or firstfew letters of a word of the search term. When the desired result isdisplayed, a result is selected and the display area 933 is updated todisplay additional information regarding the search query. In thisexample, the records and data fields of the STARBUCKS™ Coffee Locatorchannel have been searched to determine the matching search results. Inthis case, the data fields contain information related to location andtelephone contact of the STARBUCKS™ stores that match the search query.Those skilled in the art will understand how the present invention isadvantageous because simply by entering the keystrokes and selecting asingle channel, the mobile communications device displays the exact webpage or channel the user is seeking.

FIGS. 9H-9M also provide an illustration of the above. The CaltrainTrain Schedule channel (950 in FIG. 9H) has been selected to display theassociated landing page 955 (FIG. 9I) in the display area 953 of thewindow 952 of the channel. Characters of a search query are entered intothe search query field 954. When the desired result is displayed, suchas in FIG. 9I, the result heading may be selected and additionalinformation may be received. In this example, the Burlingame—MountainView schedule is selected and the schedule page 960 is displayed asshown in FIG. 9M.

Another illustrative example of the flow chart in FIG. 38 may be seen inFIGS. 10A-10C. FIG. 10A shows a window 1002 displaying the Loyola SchoolDirectory channel. The window 1002 includes a search area 1003 and adisplay area 1005. The search area 1003 includes a search query field1004. The display area 1005 of FIG. 10A includes a landing page 1007that contains instructions 1006 and other information 1008. In someembodiments, the landing page 1007 may also include links to additionalinformation (not shown). In this example, a prefix is entered into thesearch query field 1004 and display area 1005 is refreshed to showresults 1022 as shown in FIG. 10B. The search results 1022 includeinformation associated with a record. The information represents theitems contained in the data fields associated with the record. In thisexample, the additional information 1014 includes name of parent(s),name(s) of siblings, grade and name of teacher, and address, which isassociated with the record “Elayna Pacman.” As shown in FIG. 10C, whenan additional prefix is entered into the search query field 1004, thedisplay area 1005 is refreshed with new results 1024. In this example,the prefixes (“El 5”) are found across multiple data fields, thereforedisplaying results matching a name that includes “El” and a grade thatincludes “5.” In some embodiments, the result 1022 or 1024 may beselected to display additional results.

FIG. 3C is a flowchart illustrating a process 340 of client-serverinteraction during multi-prefix searching on a mobile communicationsdevice in accordance with some embodiments. An application formulti-prefix searching is initialized 341 and information is sent 342 tobe displayed in a window of the mobile communications device. A windowis displayed 343 on a display of a mobile communications device. Asearch query is input 344 into a search query field, and a confirmationis made to indicate that the search query string is complete and thesearch query is sent 344 to the server. The search query is a multi-termsearch query and contains the prefix of at least one of the terms of theentire search query. The search query is received 346 by the server,which sends 347 a result list to be displayed 348 on the mobilecommunications device. If the desired result is displayed (350—Yes), theresult may be selected 352 and additional information may be displayed.If the desired result is not displayed (350—No) the process is startedagain when another search query is input and sent to the server.

FIG. 4 is a flowchart illustrating a process 400 for interactivesearching in accordance with some embodiments. The mobile communicationsdevice displays 402 a window (902, FIG. 9A), which containsinstructions. In some embodiments, the display of the mobilecommunications device initially displays a first tier of channels, whichis obtained by submitting a base channel uniform resource location (URL)with no search terms. The system monitors 404 for the user input. Theuser then performs a sequence of actions. The user can key charactersinto the input area (as shown in FIG. 9B), or the user can select anitem from the list of headings displayed on the window. If the userinputs a key character, or keystroke, into the input area (406—Yes), theuser input field is updated 408. A query URL is constructed 410 andsubmitted by combining the base URL with the characters that the userhas inputted in the search query field. The resulting records from theURL are retrieved and the headings containing those results records isdisplayed in the output area. The system continues to wait 404 foranother user input. The aforementioned steps are repeated until the userselects an entry.

If the user did not input a key character, or keystroke (406—No), adetermination 414 is made as to whether an entry is selected. If theuser selects an entry (414—Yes), a determination 416 is made todetermine whether the entry is marked as a channel. If the entry ismarked as a channel (416—Yes), the base URL is updated 412 to the URL inthe selected record and the search query field is cleared 412. If theentry is not marked as a channel (416—No), the web browser is activatedand the browser is directed 418 to the URL in the selected record.

FIG. 5 is a flowchart illustrating a process 500 for creating amulti-term prefix index in accordance with some embodiments. Each recordof the database contains a heading and one or more URLs. The record alsocontains an indication whether each URL references a channel. Theheadings in each record are conditioned 502, which includes removingextra space characters from the beginning and end of the headings.Records with duplicate headings are removed 502. The records are sortedand assigned 504 sequential IDs. In some embodiments, the record IDs canbe used as the relevancy factors when ranking the results, therebycausing the results to be displayed in sorted heading order withouthaving to sort the headings themselves. The headings are split intowords and a list of words is constructed 506. Utilizing the list ofwords, a list of word prefixes is created and the number of incidencesis counted 508. An optimization of the list is performed. Prefixes thatdo not help to disambiguate between headings are not needed in theindex. For example, given the headings “rat,” “sat,” “saw” and “say,”the prefix “sa” disambiguates as well as the prefix “s,” so “s” does notneed to be included in the index. Entries that are prefixes of otherprefixes and have the same incidence are removed 510 from the list ofword prefixes. From the example above, “s” is a prefix of “sa” and bothoccur three times; therefore, “s” does not need to be included in theindex.

Index entries are created 512 for each prefix in each word in eachheading of the record if the prefix is in the list of disambiguatingprefixes. Each entry contains the prefix and the record ID, as well asthe position that the word occurred in the heading, which is used as arelevancy factor in ranking. The entries are sorted 514 in alphabeticalorder by prefix. The list of index entries is split 516 into lists—onelist for each prefix. The list of record IDs is compressed 518.

FIG. 6 is a flowchart illustrating a process 600 for creating a table ofcontents in accordance with some embodiments. The table of contents iscreated based on a threshold. Smaller threshold values cause the tableof contents to contain more entries, which slows the search of the tableof contents, but reduces the time spent traversing the index to findrelevant record ID lists. Larger threshold values cause the table ofcontents to contain fewer entries, which speeds the search of the tableof contents, but increases the time spent traversing the index to findrelevant record ID lists. With this trade-off in mind, the thresholdvalue is user-definable and can be adjusted to maximize prefix searchperformance on a particular hardware system and user preferences.

Process 600 begins and two offsets are initialized 602 at the start ofthe index. The record ID list that begins at the offset is retrieved 604from the index. The prefix and length are retrieved from the record IDlist. The difference between the offset and the last offset isdetermined 606. If the difference between the offset and the last offsetis smaller than the predetermined threshold (606—No), the length isadded 612 to the offset. A determination 614 is then made as to whetherthe offset is greater than the size of the index. If the offset isgreater than the size of the index (614—Yes), then the creation of thetable of contents is complete. If the offset is not greater than thesize of the index, the record ID list that begins at the offset isretrieved 604 from the index.

If the difference between the offset and the last offset is at least aslarge as the threshold (greater or equal to the threshold) (606—Yes),then the prefix and offset are appended 608 to the table of contents.The last offset is then set 610 to the offset and the length is added612 to the offset.

FIG. 7 is a flowchart illustrating a process 400 for sending interactivesearch results in accordance with some embodiments. When a query isreceived, it is split 702 into individual prefix terms. For each prefix,the record ID list corresponding to the particular prefix is retrieved704 (a detailed description of the process of this step is outlined inthe description for FIG. 8 below). A “next ID” for each list is set tobe the first ID in each list and a results list that holds certaininformation regarding each match is initialized 706. A determination 708is made as to whether the next IDs are the same for all ID lists. Ifthey are the same (708—Yes), the ID and relevancy factors are added 710to the result list, which contains a list of all record IDs thatoccurred in each of the prefix lists, and, therefore, match the query.If that ID is the last ID in any of the ID lists (712—Yes), then theresults are ordered 714 by relevancy and the result list sent 716 fordisplay.

If the ID is not the last ID on the list (712—No), the current ID isdropped 718 from each list. Again, a determination 708 is made as towhether the next IDs are the same for all ID lists. If the next IDs arenot the same (708—No), the list with the smallest next ID is selected720. If that ID is the last ID in any of the ID lists (722—Yes), theresult list is ordered 714 by relevancy and sent 716 for display. Ifthat ID is not the last ID in any of the ID lists (722—No), that ID isdropped 724 from that ID list and a determination 708 is made as towhether the next IDs are the same for all ID lists.

FIG. 8 is a flowchart illustrating a process 800 for sending interactivesearch results in accordance with some embodiments. In particular, FIG.8 is a detailed description of step 704 from FIG. 7 and illustrates theretrieval of a record ID list that corresponds to a given search term.The first part of the process 800 involves scanning the table ofcontents to find the largest entry that is no larger than the searchterm. An index offset is initialized 802 to the beginning of the index.The process is initialized 804 to start at the beginning of the table ofcontents. The next entry in the table of contents is retrieved 806, thusyielding a prefix and an offset into the index. A determination 808 ismade as to whether the prefix is less than the search term. If theprefix is smaller than the search term (808—Yes), then the index offsetis set to the offset that was retrieved from the table of contents andthe process repeats at step 806.

If the prefix is not smaller than the search term (808—No), then theindex is processed 812 at the index offset and the table of contentsscan is complete. The next entry from the index is retrieved 814. Adetermination 816 is made as to whether the prefix is smaller than thesearch term. If the prefix is smaller than the search term (816—Yes),the process repeats at step 814.

If the prefix is greater than the search term (816—No), the scanning ofthe index is completed and a determination 818 is made as to whether thesearch term is prefix of the prefix. If the search term is a prefix ofthe prefix, then the record ID list is used 820 at the index offset. Ifthe search term is not a prefix of the prefix, then no match is foundfor the particular search term.

III. Dynamic Menus

As noted above, a consistent search mechanism, particularly one thatemploys variations of the interactive, multi-prefix and multi-tiertechniques described above, facilitates targeted searches in a mobilecommunications environment by reducing the requirements for userinteraction and data entry, which in turn reduces the use of localprocessing and network bandwidth resources. As also noted above, resultsof these targeted searches are often organized into lists of “records”that share common attributes or “fields” (from train schedules and movietimes to famous people, places and events, to restaurant addresses andphone numbers, and various other diverse types of relatively structuredinformation).

As a result, these data fields, such as phone numbers, often can be“recognized” and extracted to enable actions specific to a particularrecord, such as calling a selected restaurant (even if the phone numberdata associated with that restaurant was also maintained as unstructuredtext with respect to the user's query). Other actions may becomerelevant as a result of the context of a user's query or other stateinformation (such as the time of day, or the user's location, asdetected by GPS equipment on the user's mobile phone).

Whether these additional actions are specific to one or more particularrecords or to all records within one or more particular channels, or areavailable generally among all channels (or combinations of the above),they can provide users with alternatives to simply selecting andactivating a particular record. In one embodiment, dynamic menus areemployed to enable a wide variety of alternative actions that are notonly appropriate to particular channels or records, but are alsowell-suited to the limitations of a mobile communications environment,in that they can be invoked with relatively minimal user interaction anduse of limited resources.

For example, having located a restaurant via a multi-prefix searchwithin a “favorite” local restaurant channel, a user could place a callto that restaurant via a single menu selection or push of a phone's talkbutton. Another menu selection might display a map of that restaurant,or directions from the user's current location (utilizing GPS data). Arelated search for an after-dinner movie (within a movie channel) mightinclude a different set of menu selections, such as “movie reviews” or“starring actors.” The result is a consistent targeted search mechanismacross different information domains (channels) that provides users withalternative sets of actions appropriate to the information found as aresult of one or more user queries. Users can locate this informationand invoke these ancillary actions with relatively few keystrokes, menuselections and button presses, which in turn reduces the use of localprocessing and memory resources, as well as network latency andbandwidth.

A. Dynamic Menu Architectural Overview

In one embodiment, the client portion of this (client-server) dynamicmenu mechanism is implemented as a standalone application on aresource-constrained mobile communications device, such as client 118,illustrated in FIG. 1A (components of which are further detailed asdevice 200 in FIG. 2). The architecture of this dynamic menu mechanismis based on an extensible thin-client model which, as will be explainedin greater detail below, permits the bulk of the resource-intensivefunctionality to be implemented and performed on search server 128 (alsoillustrated in FIG. 1A), rather than on resource-constrained client 118.

Such reliance on server 128 is also advantageous because mobilecommunications devices vary widely in their ability to support morecomplex functionality, such as the use of Javascript and Ajax to createinteractive web-based applications. Moreover, additional functionalitycan be implemented on server 128 without modifying any of the clientapplications 124 on client 118, thereby providing users over time notonly with the promise of new channels, for example, but also with addedfunctionality associated with one or more existing channels.

To facilitate this level of extensibility, the client (implemented, forexample, as one of the client applications 124 on client 118, andsometimes referred to herein interchangeably with client 118) providesrelatively general-purpose functionality. In other embodiments, suchfunctionality could be integrated into browser 120, or into anotherapplication such as a search engine, or into a special-purposeapplication dedicated to one or more information channels. Server 128,however, remains in control, relying upon client 118 to interpret thespecific instances of the “dynamic menu structure” provided to client118 by server 128 in response, for example, to user queries.

In one embodiment, this general-purpose functionality implemented by aclient application on client 118 includes (i) sending HTTP requests tosearch server 128 (such requests containing, for example, keystrokes ofa user's multi-prefix query or a URI resulting from a user's selectionof a channel, a record or a dynamic menu item), (ii) receiving HTTPresponses from server 128 (containing, for example, HTTP headers alongwith search results and related data), (iii) parsing these HTTPresponses (for example, to extract and render this data on the screen ofclient 118, as well as to extract dynamic menu information from the HTTPheaders), and (iv) interacting with the user of client 118 to facilitatesubsequent user queries and selections of search results or dynamic menuitems, which can be utilized to generate and send additional HTTPrequests (in some cases via browser 120), as well as to invoke“built-in” functionality on client 118, such as placing a phone call orsending an email in response to a user request.

Much of the basic search-related functionality implemented on bothclient 118 and server 128 has been explained above in great detail. Theintegrated dynamic menu mechanism described below, however,significantly extends such functionality by providing users withalternatives to simply selecting and activating a particular record.

For example, as explained above, search server 128 generates results atvarious tiers of a multi-tier user query, and sends those results toclient 118. Such results include a collection of records 142 withassociated fields 144 (illustrated in FIG. 1B), typically associatedwith a particular channel being queried by a user of client 118. A givenrecord 142 typically includes one or more fields 144 that are displayedto the user on the screen of client 118, and which identify the record(such as the name of a channel or category of channels, or an itemwithin a channel, perhaps including a name, address and phone number),as well as a field containing a URI (for example, a link) representingthe action to be performed when the user selects and activates thatrecord.

For example, when a user activates record 906 in FIG. 9B (representingthe “Starbucks Store Locator” channel), client 118 accesses the URIassociated with that record (which it previously received from server128 in response to its single prefix “St” query for a desired channel)and uses it to generate an HTTP request to server 128. In response,server 128 sends to client 118 a landing page 931 associated with thatchannel for display on client 118, as illustrated in FIG. 9C. Similarly,after the user activates the “Los Altos Rancho” record 935 illustratedin FIG. 9F, client 118 accesses the URI associated with that record(which it had received from server 128 in response to its multi-prefix“Ran I a” query for a particular Starbucks store) and uses it togenerate an HTTP request to server 128. In response, server 128 sends toclient 118 a web page 941 (with additional detail corresponding toselected “Los Altos Rancho” record 935) for display on client 118, asillustrated in FIG. 9G. Note that web page 941 could, in one embodiment,be retrieved and displayed via browser 120 without the assistance ofserver 128 while, in other embodiments, it could be retrieved by server128 and displayed on client 118 without the assistance of browser 120.

In one embodiment, Server 128 extends this functionality (to provideusers with alternatives to simply selecting and activating a particularrecord) by generating additional fields associated with the records of aparticular channel (or with multiple channels or channel categories).For example, with respect to the Starbucks Store Locator channel 906,server 128 might generate an additional field containing the phonenumber of each Starbucks store record. Server 128 would send suchadditional fields to client 118 (for example, in response to userqueries) along with the other fields noted above that identify eachrecord and provide a URI representing the action to be taken when theuser selects and activates that record. As noted above, while the phonenumber displayed in record 935 could, in one embodiment, be unstructuredtext for the purposes of a user's multi-prefix query, server 128 couldgenerate (and reformat, if necessary) a separate phone number field foreach record containing the phone number (if available) of thatparticular Starbucks store.

Moreover, in one embodiment, server 128 generates one or more HTTPheaders representing alternative actions a user could invoke, forexample, with respect to a particular selected record. Such actions canutilize not only the additional fields generated by server 128, but alsoany other data or state information discernible by client 118 (such aselapsed time or user location via GPS services).

One such HTTP header might contain a dynamic menu item that enables auser to call the phone number of a selected record. For example, if auser selects “Los Altos Rancho” record 935 and activates the dynamicmenu mechanism (rather than the action associated with the recorditself), client 118 could display a dynamic menu containing a “CallStore” item and, if the user selects that item, client 118 could thendial the phone number of the Los Altos Rancho Starbucks store (containedin the additional phone number field previously sent to client 118 byserver 128 in response to the user's multi-prefix “Ran I a” query).

As noted above, users can select a record without activating it invarious ways, depending upon the capabilities of the user's particularmobile communications device. For example, some devices have buttonsthat are dedicated (or can be assigned) to prompt a client applicationto invoke a menu. Others, such as touchscreen devices, often do notdistinguish between the selection and activation of an object, in whichcase an icon or other visible identifier could be displayed next to eachrecord, or client 118 could distinguish the number of times a record was“tapped,” or how long it had been “held down.”

In one embodiment, an HTTP header includes not only the name of thedynamic menu item that is displayed to the user (for example, “CallStore”), but also the actions to be performed when the user activatesthat dynamic menu item (whether directly or indirectly, for example, bypressing a phone button while a particular record is selected). Suchactions are designed to be extremely dynamic, taking into account notonly the context of a user's queries but also the state of the user'smobile communications device, which can change frequently.

The HTTP header architecture allows dynamic menu items to be applicableglobally to all channels, as well as to one or more particular channels,and even to particular records within or across channels. In oneembodiment, a dynamic menu item can be specified to appear only if datapertaining to that item is available for a particular selected record.For example, a “Call Store” menu item might not appear if a phone numberwas not available for the particular store record selected by the user.These HTTP headers can leverage virtually any state information known tothe user's mobile communications device (including information obtainedvia a remote server), such as a user's GPS location or whether a user islogged into a particular channel or web site.

In one embodiment, HTTP headers can reference data fields which not onlycan vary from one record to the next (such as phone numbers), but whichcan themselves contain record-specific dynamic menu item names andactions. In other words, distinct data fields can be defined (andpopulated on a per-record basis) such that the name of the dynamic menuitem itself (and its associated action) will vary from record to record,even within a selected channel (due to the ability of the HTTP header toreference these distinct data fields).

This extensible “dynamic dynamic menu” feature enables the generation ofrecord-specific, as well as channel-specific, menu items. For example, amovie channel might contain various types of field data, such as movietitles and actor names. Moreover, the “many-to-many” relationships amongsuch data might well be maintained in a relational database that can bequeried, for example, for a list of movie titles in which a given actorhas appeared, or for a list of actors that have appeared in a givenmovie. A dynamic menu could, in one embodiment, display different menuitems for search result “actor” records (for example, “Show Bio” or“Show Filmography”) than for search result “movie” records (for example,“Show Actors” or “Show Reviews”), even if a user's multi-prefix querywas applied to actors as well as movies (provided the type of searchresult could be ascertained by server 128).

The architecture of these HTTP headers, including their use of stateinformation as well as additional fields added by server 128, isdiscussed in greater detail below.

B. Dynamic Menu HTTP Header Architecture

One embodiment of this dynamic menu HTTP header architecture isillustrated in Table 1 below, which includes six distinct fields of adynamic menu HTTP header. The utility of this dynamic menu HTTP headerarchitecture will become apparent from the following explanation ofthese fields with reference to the “SAMPLE Dynamic Menu HTTP Headers”listed in Table 2 below.

TABLE 1 HTTP HEADER FIELD VALUES COMMENTS Header Name B-Menu-Entry-nnnNumber “nnn” determines Order of Menu Item within Dynamic Menu Context CCurrent Channel Indicates whether Menu Item can apply to Current ICurrent Selected Item Channel, Selected Item or BOTH B BOTH Menu Itemwill NOT be visible/enabled if Focus on Channel when “I” set or Focus onSelected Item when “C” set Processing Type I Processed IN Client UponMenu Item activation, Client issues HTTP or O Processed OUT of Clientother Request (via URI constructed in accordance (eg, Launch Browser)with “Action” field) either: To Server (to retrieve data for display INClient, and including built-in client application and mobile devicefunctionality) OR To Browser or Other Client App (launched to retrievedata OUTSIDE of Client, eg, via URI passed from Client) Next Step FFollow Link After processing the Action (specified below), Client RRefresh Channel might “Do Nothing” (N) or perform an additional SRefresh Channel and action, such as: Clear Search Filter “Follow link”(F) as if user had activated Selected N Do Nothing Item (row or record)OR “Refresh Channel” * to provide updated/refreshed data (or “S” to alsoclear any existing search filter) Menu Item Name [TEXT of Menu Itemname] This is the text that will be displayed in the Dynamic Menu MenuItems displayed in the order specified in the “Header Name” field Action*** [Used to construct URI] See explanation below regarding the processfor constructing a URI to be processed in accordance with the“Processing Type” field

TABLE 2 SAMPLE Dyamic Menu HTTP Headers B-Menu-Entry-1: BIN; Add tofavorites;http://live.boopsie.com/service/set/?favorite=$1&base=$0&uri=$2\r\nB-Menu-Entry-3; IIF; Click to call; tel:$4/; Talk\r\n B-Menu-Entry-2:IIS; Search from here;http://live.boopsie.com/service/set/?name=$1&latlon=$3&response=text\r\nB-Menu-Entry-4: CIN; Change location; i:change%20location\r\nB-Menu-Entry-6: ION; Directions to here;http://live.boopsie.com/service/directions/?latlon=$3\r\nB-Menu-Entry-5: BIS; Clear location;http://live.boopsie.com/service/set/?latlon=\r\n B-Menu-Entry-7: ION;Movie details;http://wap.aol.com/moviefone/Movie.do?theaterid=$6&movieid=$7&showtime=$8&showsynopsis=true\r\n

Each row of the SAMPLE Dynamic Menu HTTP Headers” shown in Table 2represents a distinct dynamic menu HTTP header, delimited from otherheaders (in one embodiment) by “carriage return\newline” or “\r\n”characters. Each header in turn represents a dynamic menu item (such as“Add to favorites”) that might appear when the dynamic menu is invokedand displayed on a user's mobile communications device.

As noted above, in one embodiment, users can also invoke such dynamicmenu items via built-in functionality on a mobile device, such aspressing a “Talk” button that is mapped to invoke a “Click to call”dynamic menu item. In this embodiment, the mapping occurs by adding asymbolic name to the header after the Action field (for example, “Talk”in row 2 of Table 2 to invoke this dynamic menu item whenever the clientapplication detects that the user presses the built-in “Talk” button onclient 118).

In another embodiment, these symbolic names can also be used to modifythe functionality of a dynamic menu item. For example, a “Map” symbolicname could direct the client application to pass a URI to a third-partymapping application (such as Google Maps), if one is installed on client118, rather than to a web browser, such as browser 120. In yet anotherembodiment, a web browser might automatically detect certainlocation-related information in a URL obtained from the clientapplication and elect to utilize a third-party application that it knowshas been installed on client 118 (such as Google Maps), by reformattingthe URL (intended for a web server) in accordance with a published APIdefined by such third-party application.

As noted above, in one embodiment, whenever server 128 (see FIG. 1A)sends data to client 118, it also sends a set of HTTP headers which caninclude dynamic menu HTTP headers representing dynamic menu items. Thus,a different set of dynamic menu items may be “active” depending uponwhich HTTP headers were most recently sent. In one embodiment, a set of“global” dynamic menu items is always active, along with any additionaldynamic menu items sent by server 128 at any given time. In anotherembodiment, a set of “default” dynamic menu items might become activeonce a channel has been chosen, unless the server overrides some or allof those default dynamic menu items. Many other combinations areapparent and will depend upon the requirements of any particularimplementation.

The first field of each header, illustrated in Table 1, is the “HeaderName” field. This field identifies the header as a “dynamic menu” HTTPheader by virtue of the “B-Menu-Entry-nnn” designation, where “nnn”serves to determine the order in which the “Menu Item Name” (discussedbelow) will appear when the dynamic menu is displayed. Referring to theheaders in Table 2, it can be seen that their display order isdetermined by the number following the “B-Menu-Entry-” designation, asopposed to the order in which they were transmitted to the client(reflected as the order of the rows in Table 2). For example, the headerin row 2 of Table 2 would appear as the third menu item in the dynamicmenu actually displayed to the user. Finally, note that this “HeaderName” field is delimited, in one embodiment, from the next field(“Context”) by a colon (“:”) character.

The “Context” field in Table 1 is a single-character field that relatesto the context or circumstances in which the header's dynamic menu itemwill be displayed. In other words, even when the dynamic menu isdisplayed on a user's device, not every dynamic menu item willnecessarily be displayed. In one embodiment, the dynamic menu item mightbe displayed only when the “focus” is on the current channel (C), oronly when the focus is on a particular selected record or item (I)displayed in response to a query within that channel. Otherwise, itmight always be displayed (for example, in both (B) cases) whenever thedynamic menu is displayed (assuming, in one embodiment, that referenceddata fields are non-empty).

In one embodiment, the “focus” will typically be on the “channel” (orchannel category) when results are received from server 128 (forexample, in response to a user query or menu selection). But, when auser selects (but does not activate) a particular item or record withina channel, the focus is then switched to that particular item or record.

The header in row 3 of Table 2, for example, containing a “Search fromhere” dynamic menu item, would, in this example, not be displayed unlessthe focus was on a particular selected record or item (I). In the caseof a “Yellow Pages” channel, for example, it would not make sense(contextually) to display a “Search from here” dynamic menu item beforethe user enters a search query (in which case no records would bevisible) or after the user enters a partial or complete query but beforethe user selects a record (in which case multiple items might bevisible). But, once the user selects a particular record, it makes sensein this context to display the “Search from here” menu item, which, ifactivated, would replace the “reference location” for future searcheswith the location associated with that selected store. As noted above,however, in the event that the particular selected store did not have alisted address, then the client application could detect that the“address” field was empty and (using a different mechanism discussedbelow) prevent the display of the “Search from here” menu item for thatparticular selected record.

In the case of the “Add to favorites” header in row 1 of Table 2, the“B” designation indicates that this function could apply to the currentchannel as well as to the selected item. Continuing with the aboveYellow Pages example, if the focus is still on the channel (for example,before the user enters a query and selects a record), then activation ofthe “Add to favorite” dynamic menu item would add the Yellow Pageschannel to the user's list of “favorites.” But, if the user selects aparticular store, and then activates the “Add to favorite” dynamic menuitem, then the selected store (not the Yellow Pages channel) would beadded to the user's list of “favorites.”

Yet, the “Change location” header in row 4 of Table 2 would only bedisplayed if the focus was on the channel, as opposed to a particularrecord (due to the “C” designation in the Context field). Continuingwith the Yellow Pages example, consider the scenario in which a userfirst activates that channel, and has not yet entered a query. If theuser had previously set a “search center” location, then the clientapplication might initially display a list of stores nearest thatlocation. But, if the user desires to search for stores in anothergeographical area, then the user most likely would not select one ofthose displayed store records. Instead, the user could activate the“Change location” dynamic menu item, which might display a list of zipcodes and prompt the user to enter zip code digits until the user seesand activates a desired zip code. The user might then enter a query intothe Yellow Pages channel, resulting in the display of a list of storesnearby the user's new “search center” location.

Note that, in the SAMPLE Dynamic Menu HTTP Headers in Table 2, the“Context” field (in one embodiment) has no delimiter, as it is asingle-character field followed by another single-character field, the“Processing Type” field, which also has no delimiter, as it is followedby a third single-character field, the “Next Step” field, which has asemicolon (“;”) delimiter to separate it from the following “Menu ItemName” field.

Returning to Table 1, the “Processing Type” field indicates whether,upon activation of the dynamic menu item by the user, the associatedaction will be performed inside (I) this client application (includinginvocation of a built-in feature of the user's mobile device, such asplacing a phone call) or outside (O) this client application (forexample, by launching another client application, such as a web browseror mapping application). In either case, as will be discussed below withrespect to the “Action” field shown in Table 1, activation of thedynamic menu item will result in generation of a URI, which will eitherbe transmitted to server 128 (or handled internally, for example, viabuilt-in functionality) or be passed to another client application, suchas web browser 120.

Returning to Table 2, it is apparent that many of the actions associatedwith these headers are performed inside (I) the client application. Forexample, in addition to the “Add to favorites,” “Change location” and“Search from here” headers, the “Clear location” header in row 6 ofTable 2 will also direct the client application to transmit an HTTPrequest (containing the relevant URI) to server 128 (or, in otherembodiments, to third-party servers hosting particular channelfunctionality). Instead of setting the user's “latlon” variable to aselected “zip code” value (containing the latitude and longitudecoordinates corresponding, for example, to a desired zip code), theclient application would request that server 128 clear that variable bysetting it to a null value. Even the “Click to call” header in row 2 ofTable 2 will utilize the client application to invoke built-infunctionality of the user's mobile device (in this case, to place a callto a selected item, such as a store or movie theater).

Other headers in Table 2, however, include actions that are intended tobe performed outside (O) the client application, for example by invokinganother client application, such as a web browser. For example, the“Movie details” header in row 7 of Table 2 directs the clientapplication to construct a URI utilizing various field data (discussedbelow) and then pass it to a client web browser to retrieve a web pagefrom a third-party web server. Moreover, the “Directions to here” headerin row 5 of Table 2 will appear only if the user selects a particularitem, which typically will include one or more location fields. In oneembodiment, the client application will pass the relevant locationinformation (for the starting “search center” as well as the destinationof the selected item) to another client application, such as a webbrowser, which will retrieve a web page containing relevant directions(and perhaps a map of the route). In another embodiment, a dedicatedmapping application could be employed instead of a web browser.

The “Next Step” field in Table 1 is also a single-character field thatindicates whether the client application, after it performs the actionassociated with this dynamic menu header, will perform another action.For example, a “Follow Link” (F) action would instruct the clientapplication to perform the same action that it would have performed hadthe user activated the selected record. For example, after performingthe action associated with the “Click to call” header in row 2 of Table2 (such as calling the phone number associated with a selected store orother record), the client application will then follow the linkassociated with that selected item (for example, by passing itsassociated URL to web browser 120 to retrieve a merchant's web page). Inanother embodiment, in which client 118 cannot initiate voice and datacommunications simultaneously, the (F) designation could be ignored.

Other options include a “Refresh Channel” (R) action, in which thecurrent channel is refreshed by virtue of the client application againsending the most recent HTTP request to server 128 (or, in otherembodiments, to another third-party server hosting channel data). As aresult, server 128 sends back updated results to the client applicationand the screen is refreshed. A related option is the “Refresh Channeland Clear Search Filter” (S) action, which clears any search filter(such as a multi-prefix search query) from the HTTP request beforesending it to server 128.

For example, if a user searched a “Starbucks Store Locator” channel fora store near a particular city, and saw a nearby store in the resultslist, the user might select that store record and activate “Search fromhere” dynamic menu item, which would update the user's “search center”based upon the location of that selected store. In that case, however,the user likely would want to see updated search results reflecting thenew location, but would not necessarily want those results filtered byany particular city. The “S” designation in the “Search from here”header in row 3 of Table 2 would direct the client to issue a “Refresh”request after removing the existing search filter. Note that, in oneembodiment, all of these steps occur without requiring the user to leavethe client application, access the web browser or supply a user IDexternally.

The fourth and final “Next Step” action is to “Do Nothing” (N), in whichcase the client application performs only the action specified in the“Action” field shown in Table 1. For example, the “Add to favorites”header in row 1 of Table 2 would simply add the channel or selectedrecord to the user's list of “favorites” (due to the “N” designation inthe header's “Next Step” field). In another embodiment, a different“Next Step” action might cause the user's list of “favorites” to appear(for example, as it would when the client application is initiallyinvoked). As noted above, the “Next Step” field, in one embodiment, isdelimited by a semicolon (“;”).

The next to last field illustrated in Table 1 is the “Menu Item Name”field which, in one embodiment, is also delimited by a semicolon (“;”)to separate it from the final “Action” field. This “Menu Item Name”field contains the text of the name that will appear in the dynamic menuwhen it is displayed to the user on the screen of client 118. As notedabove, the order of these menu items is determined by the “Header Name”field.

The sixth and final field of the embodiment of a dynamic menu HTTPheader illustrated in Table 1 is the “Action” field. This fielddetermines the action that the client application will perform if thedynamic menu item in this header is activated by the user. This fieldprovides a flexible and dynamic mechanism that facilitates theconstruction of a URI that can be sent to server 128 (or used to invokea built-in function of the user's mobile device) or passed to anotherclient application, such as browser 120 (depending upon the value of the“Processing Type” field discussed above).

The dynamic features of this Action field, in one embodiment, includethe ability to extract data fields associated with a current channel orselected record by referencing a “field number” or “column” with adollar sign (for example, “$1” for field 1, and so forth). The text inthe data field associated with the referenced column replaces thereference (“$1”) and is inserted into the URI under construction.Moreover, the URI can include variable names to which a server willassign values, such as the value of a referenced data field (such as“varname=$1”).

For example, the action associated with the “Add to favorites” header inrow 1 of Table 2 is a template for a URI the first portion of which (forexample, http://live.boopsie.com/service/set/) appears to be a typicalHTTP request to server 128 (or, in another embodiment, to another serverhosting channel data). Based upon its use of the service/set directorystructure, server 128 (in one embodiment) implicitly knows to setvariables to specified values based upon the remainder of the URI(following the “?” delimiter, indicating that parameters will follow).

In this case, the remaining portion of the URI consists of threevariable assignments separated by “ampersand” (“&”) delimiters, followedby (as noted above) “carriage return/newline” or “\r\n” characters,which serve to separate individual dynamic menu HTTP headers from oneanother. Thus, the “favorite” variable will be assigned the valuecontained within “field 1” (in one embodiment, the name of a channel,category or selected record). The “base” variable is used, in oneembodiment, to provide a standard reference directory location (storedin “field 0”) to which additional directories can be appended, such asthe “uri” (assigned to the value of “field 2”), which might contain thechannel-specific location, for example, of the selected favoritechannel.

Looking at row 2 of Table 2, this “Click to call” dynamic menu item willperform a special “tel” action that is built into the user's mobiledevice and accessible from the client application. In one embodiment,the client application would extract the data from “field 4” (forexample, the phone number of the selected record) and pass it to thebuilt-in function of the user's mobile device to initiate a phone call.Depending upon the capabilities of this built-in functionality, thephone number might be dialed automatically, or a dialog box might pop updisplaying the phone number and asking the user whether to initiate thephone call. As noted above, this functionality can even be invokedwithout requiring the user to activate the dynamic menu item. Forexample, if the client application detects that the user pressed the“Talk” button on client 118, it would know to invoke this “Click tocall” dynamic menu item due to the presence of the symbolic name “Talk”after the Action field in this header, as shown in row 2 of Table 2.

The “Action” field of the “Search from here” dynamic menu item in row 3of Table 2 is similar to that of the “Add to favorites” item discussedabove. The “name” variable is set to the value of “field 1,” whichrepresents the name of the selected record whose location is being usedas the new “search center.” The “latlon” variable is set to the value of“field 3,” which contains the latitude and longitude data defining thelocation of the selected item. The “response” variable simply indicates,in one embodiment, that the server is to generate a textual response, asopposed to returning a web page.

The “Change location” action in row 4 of Table 2 is a special command,in one embodiment, to enable the current channel to be changedtemporarily and then refreshed after the user specifies a new “searchcenter” location. For example, upon activating the “Change location”dynamic menu item, the special URI sent to server 128 requests atemporary change of channel (the data for which is located via that URI)in response to which server 128 sends a list of zip codes (the datacorresponding to a “Change location” channel) to be displayed on theclient. The user can then search into, select and activate a desired zipcode, whereupon the user will be returned to the prior channel, whichwill be refreshed to reflect the new location.

The “Directions to here” action in row 5 of Table 2 is processed, in oneembodiment, outside the client (based on the “1” designation in the“Processing Type” field) and passed to web browser 120 on the user'smobile device. The URI will also include the user's current “searchcenter” location (not shown). In one embodiment, this URI is sent viaweb browser 120 to a web server on server 128 which, based on the use ofthe “directions” directory, will set the “latlon” variable to the valueof the data extracted into the URI from “field 3,” and use both the “to”and “from” locations passed in the URI to return a web page containing,for example, a map along with textual directions. In one embodiment,server 128 relies upon a third-party web server to return this web page,after passing it the location data.

The “Action” field of the “Clear location” dynamic menu item in row 6 ofTable 2 is also similar to that of the “Add to favorites” item discussedabove. The “latlon” variable is set to the value of “field 3,” whichcontains the latitude and longitude data defining the location of theselected item. After setting this variable, server 128 is directed (bythe “S” designation in the “Next Step” field) to clear the search filterand refresh the currently selected channel (as described above).

The “Action” field of the “Movie details” dynamic menu item in row 7 ofTable 2 is processed outside of the client application (as is the“Directions to here” dynamic menu item). In this case, the user, afterquerying the AOL Moviefone channel for a desired movie, selects thatmovie record and activates the “Movie details” dynamic menu item. Theclient application constructs a relatively complicated URI (explainedbelow) and passes it to web browser 120. In one embodiment, this URI issent via browser 120 to a third-party site (AOL's Moviefone web site)with a standard HTTP command and a set of parameters (assigning dataextracted from channel data columns to specified variables). The“Movie.do” command instructs the Moviefone web server to return a “moviedetails” web page to browser 120 based upon the specified parametervalues.

The “theaterid” variable is set to the data extracted into the URI from“field 6” (containing a unique ID of the theater at which the selectedmovie is playing). The “movieid” variable is set to the data extractedinto the URI from “field 7” (containing a unique ID of the selectedmovie). The “showtime” variable is set to the data extracted into theURI from “field 8” (defining showtimes for the selected movie). Finally,the “showsynopsis” variable is set to a constant value of “true,”indicating that the selected movie's synopsis should be included withthe other movie details.

As noted above, in one embodiment, dynamic menu items are not displayedif data fields referenced in a header's “Action” field (for example,using the “$” replacement mechanism discussed above) are empty. Thisbehavior can be modified, in another embodiment, by including a“question mark” (“?”) character after the “$” character (for example,“$?1”), in which case the dynamic menu item would be displayed even ifthe referenced data field is empty. Similarly, use of an “exclamationpoint” (“!”) character (for example, “$!1”) would invert this behavior,and cause the dynamic menu item to be displayed only if the referenceddata column is empty. In yet another embodiment, a “percent” (“%”)character (following a “$” or “$?” or “$!” character combination) willdirect the client application not to URL-encode the referenced fielddata.

In still another embodiment, a “$p” character combination is used toreference the mobile device's GPS latitude/longitude coordinates (if GPSfunctionality is present on the device). An HTTP header sent by server128, such as “B-GPS: 45.394280, 132.224830,” could inform the client ofthe current “search center” location (for example, previously set by theuser via a “Search from here” dynamic menu item). In another embodiment,client 118 sends a standard “geo.position: lat; Ion” header to server128 with every request, which server 128 can use, for example, to sortsearch results. In other embodiments, additional HTTP headers can beemployed to cause channel “refreshes” under program control. Forexample, a “B-Action: refresh=10 sec” header would direct the client torequest a refresh of the current channel every 10 seconds. Such afeature could be useful, for example, to obtain updated sporting eventscores (perhaps even based upon the time remaining in an event).Similarly, a “B-Action: refresh=0.25 mi” header would direct the clientto request a refresh of the current channel whenever the user's mobilephone device had traveled one-quarter of a mile (as indicated by the GPSdata). This feature could be useful to update a map, for example,showing the nearest Starbucks locations while the user is traveling, orthe nearest “homes for sale” while a realtor is driving across town.Server 128 could also notify client 118 when the user is within acertain distance of a selected destination.

Many other dynamic menu and related features will become apparent in thecontext of the following discussion of operational aspects of dynamicmenus with reference to FIGS. 11A-C and FIGS. 12A-G below.

C. Dynamic Menu Operation

Referring to FIG. 11A, a client application in one embodiment of thepresent invention displays a window 1102 when initially invoked by auser of a mobile communications device (such as client 118 in FIG. 1A ordevice 200 in FIG. 2) on which the client application is loaded. Itshould be noted that another similar embodiment of window 1102 is alsoillustrated as window 902 in FIG. 9A.

In one embodiment, Window 1102 contains various component display areas,including a small area 1103 for display of real-time and related statusinformation, such as the level of network connectivity to a mobilecommunications or other network. It also includes a search query field1104, to facilitate the entry of user queries, including themulti-prefix queries discussed above, as well as a results display area1105 to display the results of such user queries.

When the client application is initially invoked, results display area1105 contains a list of various categories of channels, including auser's previously designated “favorite” channels 1106 (as well as linksand other previously designated records) and other available channelcategories 1107. As noted above, results are provided to client 118 byserver 128 (typically in response to user requests), and may be updatedover time. In addition, window 1102 may display certain headings, suchas the “Favorite Channels” heading 1108, which describes the collectionof user-defined “favorites” displayed below heading 1108 (but whichcannot, in one embodiment, be selected or activated to perform anyadditional function).

In one embodiment, window 1102 also includes a “fixed menu” display area1109 containing certain commonly-used features, such as a “Back” menuitem that will refresh window 1102 with the results of the previouslyentered user query (in one embodiment, by resending the prior userrequest to server 128 and displaying the updated results of suchrequest). A “Menu” item is also included in display area 1109 to invokea menu with a set of items that provide additional functionality, aswill be explained below. In one embodiment, the “Back” and “Menu” itemscan be mapped to and invoked by keystrokes or buttons on the user'smobile device.

At this point, a user typically desires to locate a desired channel (forexample, in a “first-tier” search) within which desired information canthen be located (for example, via a “second-tier” or subsequent-tierquery). To facilitate user queries, a user can enter characters intosearch query field 1104, or simply select and activate a channel orchannel category. In either case, client 118 submits such user requeststo server 128, which returns a collection of filtered results whichclient 118 displays in results display area 1105. Examples of suchmulti-tiered and multi-prefix user queries have been illustrated abovein great detail.

In other situations, however, users desire additional functionalitybeyond that which is afforded by simply entering user queries andactivating channel, channel category and intra-channel records. Asdiscussed above, the dynamic menu architecture of the present inventionprovides such alternative functionality in the context of the user'squery and other related state information.

In one embodiment, when the user initially invokes the clientapplication, client 118 sends an HTTP “GET” Request as illustrated inTable 3 below. This request includes the “imenu” function and areference to the “Home” directory, which is interpreted by server 128 asa request for the initial “top-level” set of channels, categories andfavorites that is illustrated in FIG. 11A. The remaining informationcontains data regarding the capabilities of the mobile device, such asits operating system and version, and display resolution, as well as theversion of the client application.

In response, server 128 also sends a “GET” request, which directs client118 to display the “list” of data that follows the HTTP headers. Server128 also informs client 118 that the “Incremental Search” capability isturned “on” (to provide interactive results as the user types charactersinto search query field 1104 in FIG. 11A). Finally, it indicates thelength of the data that follows.

The HTTP headers include 3 dynamic menu headers (“Remove fromfavorites,” “Add to favorites,” and “Refresh”), as well as a “B-Action:skip-empty-links” header that directs the client, while navigating, toskip over rows of data that do not have associated links (for example,to avoid selecting items such as the “Favorite Channels” heading 1108 inFIG. 11A, since it has no associated action). As explained above, the“Refresh” dynamic menu item will request that server 128 refresh thecurrent channel and remove the user's current search filter, if any. Itwill be visible regardless of whether the focus is on any selectedchannel or category.

The “Add to favorites” and “Remove from favorites” dynamic menu itemswill apply only when an item is selected (due to the “I” designation inthe “Context” field), and will refresh this top-level collection ofchannels and categories to update the list of the user's “favorites”(for example, after adding or removing a selected item). The Actionfields of these two headers is similar to that explained in the examplesabove in Table 2, in that it sets the “base,” “favorite,” and “uri”variables to the values of the data in fields 0, 1, and 2, respectively.In addition, the “Remove from favorites” Action field includes a“remove” parameter to enable server 128 to distinguish this request froman “Add to favorites” request.

Note, however, that a third field (“field 3”) is referenced, which isused by client 118 to determine whether to display the “Add tofavorites” or “Remove from favorites” dynamic menu item based on whetherthe user selected an item on the user's list of favorites. For example,as will be discussed below, each record includes (in one embodiment) a“1” in “field 3” if it is on the user's list of favorites. Otherwise,“field 3” is left empty. By using the “$3” designation, the “Remove fromfavorites” dynamic menu item will be displayed only if “field 3” isnon-empty, and thus only if the user has selected an item on the user'slist of “favorites.” Conversely, the “Add to favorites” dynamic menuitem contains a “$13” designation, which directs client 118 to displaythis menu item only if “field 3” is empty, and thus only if the user hasselected an item that is not on the user's list of “favorites.”

Following these HTTP headers in Table 3 is the body of the transmittedmessage containing the list of data to be displayed by client 118 inresults display area 1105 of window 1102 shown in FIG. 11A. Thehex-formatted digits at the beginning of certain rows of data specifystandard color and aesthtic display information. The “name” to bedisplayed for each channel or category (or header) is deemed “field 1”with a space delimiter separating it from the “uri” in “field 2.” This“uri,” in one embodiment, is a relative path to assist server 128 inlocating the data (HTTP headers and channel data) should a particularrecord be selected and activated. Following the “uri,” the data for“field 3” is displayed, which (in one embodiment) includes a “1” if therecord is on the user's list of “favorites,” and is otherwise leftempty.

To illustrate how these HTTP headers and associated data records shownin Table 3 are utilized, consider a common scenario illustrated in FIG.118. A user might desire to remove a previously defined favorite channel(or other record). In one embodiment, the user selects a favoritechannel which the user desires to remove, such as “Loyola SchoolDirectory” channel 1116 in window 1112, and invokes menu item 1119 a inmenu display area 1119, which results in the display of dynamic menu1115. At this point, client 118 detects that selected record 1116 is onthe user's list of favorites (based on the presence of a “1” in “field3”), and thus displays the “Remove from favorites” dynamic menu item1115 a (but not the “Add to favorites” dynamic menu item, due to the“$!3” designation in its header). It should also be noted that, in oneembodiment, additional menu items are displayed (for example, “Home” and“All Channels” and others) on dynamic menu 1115. These “global” menuitems can be “hardwired” into client 118 (for example, not relying onthis dynamic menu HTTP header architecture), or can be considered as“default” menu items to be displayed unless server 128 indicatesotherwise (as discussed above).

Having selected channel 1116, the user can select and activate “Removefrom favorites” dynamic menu item 1115 a, which will cause client 118(in accordance with the Action field associated with the “Remove fromfavorites” header illustrated in Table 3) to construct a URI (extractinginformation from designated data fields) and send an HTTP request toserver 128, which will set the relevant variables (as explained above).It will then issue a “Refresh” request (due to the “R” designation inthe “Next Step” field) to server 128 to refresh this “top-level” channeland category list, reflecting the removed record.

If, however, the user selects a record that is not on the user's list of“favorites,” then the “Remove from favorites” item is not contextuallyrelevant and is not displayed (in one embodiment) when the user invokesa dynamic menu. Turning to FIG. 11C, for example, if the user selects arecord such as “Business” channel category 1126, and then invokes menuitem 1129 a in menu display area 1129, client 118 displays dynamic menu1125, which does not contain a “Remove from favorites” dynamic menuitem, but does contain an “Add to favorites” menu item 1125 a.

As discussed above, client 118 detects that selected “Business” channelcategory record 1126 is not on the user's list of favorites (based on anempty “field 3”), and thus displays the “Add to favorites” dynamic menuitem 1125 a (but not the “Remove from favorites” dynamic menu item, dueto the “$3” designation in its header). Having selected channel 1126,the user can select and activate “Add to favorites” dynamic menu item1125 a, which will cause client 118 (in accordance with the Action fieldassociated with the “Add to favorites” header illustrated in Table 3) toconstruct a URI (extracting information from designated data fields) andsend an HTTP request to server 128, which will set the relevantvariables (as explained above). It will then issue a “Refresh” request(due to the “R” designation in the “Next Step” field) to server 128 torefresh this “top-level” channel and category list, reflecting the addedrecord.

One embodiment of the dynamic menu mechanism illustrated in FIGS.11A-11C provides users with contextually relevant alternativefunctionality not only by distinguishing whether a selected record is onthe user's list of favorites (and displaying the contextuallyappropriate dynamic menu item), but also by receiving dynamic menu HTTPheaders along with the results of the user's request. In other words, asthe user queries different channels for different types of data, thedynamic menu items also can change to reflect such differences, even atthe level of a particular record.

TABLE 3 REQUEST GET /imenu?u=http://live.boopsie.com/i/Home/ HTTP/1.1UA-OS: WinCE (Smartphone) - Version (5.1); Carrier (none); Boopsie -Version (2.0.2.2) UA-pixels: 320x240 (9 lines) RESPONSE (not logged in)GET /list HTTP/1.1 Incremental-Search: on Content-Length: 1017B-Menu-Entry-1: IIR; Remove from favorites;http://live.boopsie.com/service/set/?remove&favorite=$1&base=$0&uri=$2&if=$3B-Menu-Entry-2: IIR; Add to favorites;http://live.boopsie.com/service/set/?favorite=$1&base=$0&uri=$2&if=$!3B-Menu-Entry-4: BIS; Refresh B-Action: skip-empty-links #fff#008Favorite Channels CitySearch Silicon Valleyi:../CitySearch%20Silicon%20Valley/ 1 Google Gmail http://gmail.com/ 1Loyola School Directory i:../Loyola%20School%20Directory/ 1 Nokia MusicStore i:../Nokia%20Music%20Store/ 1 Wikipedia English The FreeEncyclopedia i:../Wikipedia%20English%20The%20Free%20Encyclopedia/ 1#fff#35a All Channels i:../All%20Channels/ #fff#35a Businessi:../Business/ #fff#35a Dating i:../Dating/ #fff#35a Entertainmenti:../Entertainment/ #fff#35a Food and Wine i:../Food%20and%20Wine/#fff#35a Google i:../Google/ #fff#35a Health i:../Health/ #fff#35a HowTo i:../How%20To/ #fff#35a Local i:../Local/ #fff#35a News i:../News/#fff#35a Reference i:../Reference/ #fff#35a Religion i:../Religion/#fff#35a Shopping i:../Shopping/ #fff#35a Social Networkingi:../Social%20Networking/ #fff#35a Sports and Recreationi:../Sports%20and%20Recreation/ #fff#35a Store Locatori:../Store%20Locator/ #fff#35a Technical i:../Technical/ #fff#35a Toolsi:../Tools/ #fff#35a Travel i:../Travel/

Referring now to FIG. 12A, consider the operation of one embodiment ofthe dynamic menu mechanism of the present invention in the context of auser activating the “Facebook Friends” channel. Upon locating andactivating this channel (in the manner discussed above), client 118sends a “GET” request to server 128, illustrated in Table 4. Thisrequest is very similar to the one shown in Table 3, the primarydifference being the URI path to the “Facebook Friends” directory onserver 128, instead of to the “Home” directory (containing the list ofchannels, categories and favorites).

Yet, server 128 detects that the user has not yet logged into theFacebook web site (at least via the client application), and thus cannotyet leverage the client application (including, for example, theinteractive multi-prefix, multi-tier and dynamic menu features of thepresent invention) to obtain user-specific profile information,including information regarding the user's Facebook friends. Althoughthe user could be logged into the Facebook web site via web browser 120,this would not afford the user the benefits of the integrated experienceprovided by the Facebook Friends channel (described in greater detailbelow).

In one embodiment, before server 128 delivers to client 118 the “Loginto Facebook” page shown in FIG. 12A, server 128 accesses the Facebookweb server (via a published API), obtains an “API key” (in effectlogging server 128 into Facebook) and provides information to Facebook,including a “user callback URL” that the Facebook web server will supplyto browser 120 in response to a successful authentication request (whichcontains the API key). When browser 120 subsequently accesses this “usercallback URL,” it will access the web browser on server 128, effectivelynotifying server 128 of the user's successful authentication, andproviding it with the user's “session ID” generated by the Facebook webserver.

By leveraging this relatively common API mechanism (and other techniquesdiscussed in greater detail below), server 128 can provide users with asignificant degree of interoperability between the client-serverapplication of the present invention and standard web browsers such asweb browser 120. For example, because the Facebook web server is awareof server 128 (via the API key), it can deliver to browser 120 the “Loginto Facebook” web page shown in FIG. 12A, which includes informationspecific to the client-server application of the present invention (forexample, the message 1207 requesting the user to log into Facebook toenable the “Boopsie” application to deliver the user's list of friends).

Returning to Table 4, the “GET” request in the “Response” from server128 is also very similar to the one discussed above and shown in Table3. The associated data is relatively simple, including only textualdirections to the user and a single selectable record with an associated“login” action. The single dynamic menu “Refresh” HTTP header is verysimilar to the Refresh header shown in Table 3, except that it does notclear the user's search filter (due to the “R” designation in theheader's “Next Step” field).

One major difference, however, is the presence of security information,since the user must log into (albeit somewhat Indirectly) the actual“Facebook” web site. In one embodiment, server 128 generates a “MOFIID,”which is a form of user or session ID that is specific to the “pairing”of the user and a particular channel, such as the Facebook Friendschannel. To enhance security, each user is assigned differentauthentication credentials with respect to each channel the useraccesses (assuming such channels or web sites require userauthentication). This strengthens security (as will become apparentbelow) by preventing multiple web sites from having access to a user's“common” authentication credentials, while still affording server 128the ability to communicate with the Facebook web server on behalf of theuser to obtain user-specific information and provide enhancedfunctionality to users of both the Facebook web site and the FacebookFriends channel.

The “B-MOFIID: 2wI6n9pX5z4cV” header shown in Table 4 provides theuser's MOFIID to the client application. In addition, the URI (shown inTable 4) associated with the user's activation of the “Log intoFacebook” record (illustrated in FIG. 12A) contains both the API key(connecting server 128 with Facebook) and the MOFIID (used by server 128to distinguish among users of the Facebook Friends channel). Thesemechanisms are used, in one embodiment, to enable users to log intoFacebook via a standard web browser, such as browser 120, withoutforegoing the functionality provided by the Facebook Friends channel.

At this point, the user's only effective choice is to activate the “Loginto Facebook” link or record 1206 to initiate the login process. In oneembodiment, the client application then passes the URI shown in Table 4to browser 120, which the client application launches to initiate theprocess of logging the user into the Facebook web site. In response, theFacebook web server delivers to browser 120 the web page 1212 shown inFIG. 128. Note that this web page also includes information specific tothe client-server application of the present invention, such as themessage 1214 requesting that the user log into Facebook via web page1212 to enjoy the full functionality of the “Boopsie” application.Message 1214 also provides the user with an optional link to log intoFacebook directly (for example, if the user desires to circumvent the“Boopsie” client application and the benefits afforded by the FacebookFriends channel).

Web page 1212 includes fields in which the user can enter standardauthentication information, including email address or phone numberfield 1216, password field 1217 and an optional save login info checkbox1218. After filling in the relevant login info, as illustrated in FIG.12C, and activating the “Log In” link 1225, the Facebook web serverproceeds not only to log the user into Facebook and generate a sessionID (for subsequent access to user-specific information on the Facebookweb site), but also to use the “user callback URL” described above toredirect web browser 120 to a web page on server 128 corresponding tothat URL (as well as provide the user's session ID). This processeffectively serves to notify server 128 of the user's successfulFacebook login, as well as provide server 128 with the user'snewly-generated Facebook session ID. Server 128 utilizes the user'sMOFIID (which is also forwarded by the Facebook web server, along withthe session ID that it generated) to distinguish among its own usersthat access the Facebook Friends channel.

At this point, server 128 can utilize the user's MOFIID and session IDto issue requests to the Facebook web server for user-specificinformation, such as the user's list of friends. However, in oneembodiment, rather than leave the user in the web browser interface, theweb server on server 128 can respond to the request from browser 120(for the web page at the “user callback URL” located on server 128) bydownloading a “.MOFI” file, which will cause browser 120 to invoke theclient application automatically—much in the same way that anydownloaded file with an extension to a third-party application (such as“.xls” for Microsoft Excel or “.pdf” for Adobe Acrobat), can cause a webbrowser to launch that application automatically upon downloading thatfile.

This non-standard use of a relatively standard mechanism enables theuser, after having logged into Facebook via browser 120, toautomatically be returned to the client application providing theFacebook Friends channel.

TABLE 4 REQUEST GET/imenu?u=http://live.boopsie.com/i/Facebook%20Friends/ HTTP/1.1 UA-OS:WinCE (Smartphone) - Version (5.1); Carrier (none); Boopsie - Version(2.0.2.2) UA-pixels: 320x240 (9 lines) RESPONSE (not logged in) GET/list HTTP/1.1 Incremental-Search: on Content-Length: 257 B-MOFIID:2wl6n9pX5z4cV B-Action: skip-empty-links B-List-Mode: refreshsB-Menu-Entry-1: BIR; Refresh #fff#3b5998 facebook #fff#6d84b4 please login Please log in, so that Boopsie for Facebook may load your Friendslist. Log into Facebook\thttp://m.facebook.com/login.php?api_key=4a7075ed59a1884c5e741c13a83c25e0&v=1.0&next=mofiid%3d2wl6nghj5z4cV

When the client application “refreshes” its request for the “FacebookFriends” channel (automatically upon activation, for example, in oneembodiment), it reissues the same GET request, now shown in Table 5.However, because server 128 now knows that the user is logged intoFacebook, it issues a different response, illustrated in FIG. 12D.

The HTTP headers shown in Table 5 include the MOFIID data and progressinformation (indicating, for example, that records 1 to 20 of 97 recordshave been retrieved), as well as seven dynamic menu HTTP headers thatprovide functionality specific to the Facebook Friends channel, inaddition to the data that follows, which includes a list of the user'sfriends and identifying information (including a unique “friend ID” thatserver 128 can use to obtain information specific to a particular“friend” record from the Facebook web server).

Turning to FIG. 12D, window 1232 includes user search query field 1234and results display area 1235, which contains data headings 1238indicating that Facebook friends 1-20 of 97 are displayed below. These“friend” records 1236 contain summary information about the user'sfriends. If any such record is activated, an associated action will beperformed, such as invoking web browser 120 to request a “deep link”from the Facebook web site for a profile of the selected friend. Inaddition, menu display area 1239 includes menu item 1239 a, whichenables the user to display a dynamic menu.

The dynamic menu HTTP headers shown in Table 5 provide a variety ofFacebook-specific functionality. With the exception of the “Refresh” and“Log out” headers, which are performed by the client application, theremaining headers contains URIs that, when constructed, will be passedto browser 120. Yet, using the mechanisms discussed above with respectto the Facebook login process, the client application can be invokedfrom browser 120, enabling additional functionality to be performed fromwithin the client application, apart from simply issuing a “deep link”and leaving the user in the web browser.

The “My Profile” header references a location on server 128 in which theuser's Facebook profile information is stored. The other dynamic menuheaders extract the ID of a selected friend (using, for example, the“$2” replacement mechanism discussed above) to enable server 128 toobtain information relating to that friend from the Facebook web serveron behalf of the user (using the “session ID” and “MOFIID” as discussedabove).

If the user selects a particular friend, such as friend record 1246shown in FIG. 12E and invokes dynamic menu 1245 (for example, via menuitem 1239 a in FIG. 12D), the user can elect to perform variousalternative Facebook-specific functions related to that selected friend(apart from the retrieval of that selected friend's profile, forexample, by activating the selected friend's record). For example, theuser could activate dynamic menu item 1245 a to “poke” selected friend1246 (via Facebook).

Upon activation of the “Poke friend” dynamic menu item 1245 a, theclient application constructs the URI (from the Action field shown inTable 5), and passes it to browser 120 (including the “poke” parametercontaining the selected friend's user ID extracted from “field 3” of thedata shown in Table 5). In one embodiment, after “poking” the selectedfriend, browser 120 may notify the user that the “poke” was successfuland then (using the “.MOFI” technique discussed above) automaticallyinvoke the client application, which will “refresh” the user's list offriends. In another embodiment, the user will remain in the browser 120,but can still return manually to the client application, which will berefreshed automatically.

TABLE 5 REQUEST (same as before) GET/imenu?u=http://live.boopsie.com/i/Facebook%20Friends/ HTTP/1.1 UA-OS:WinCE (Smartphone) - Version (5.1); Carrier (none); Boopsie - Version(2.0.2.2) UA-pixels: 320x240 (9 lines) RESPONSE (logged in) GET /listHTTP/1.1 Incremental-Search: on Content-Length: 1140 B-MOFIID:2wl6n9pX5z4cV B-Action: skip-empty-links B-Progress: 1 to 20 of 97B-Menu-Entry-1: ION; Add to friends;http://live.boopsie.com/host/facebookfriends/?add=$4 B-Menu-Entry-2:ION; Poke friend; http://live.boopsie.com/host/facebookfriends/?poke=$3B-Menu-Entry-3: ION; Message friend;http://live.boopsie.com/host/facebookfriends/?message=$3 B-Menu-Entry-4:ION; Wall of friend;http://live.boopsie.com/host/facebookfriends/?wall=$2 B-Menu-Entry-5:BON; My profile; http://live.boopsie.com/host/facebookfriends/?profileB-Menu-Entry-6: BIS; Refresh B-Menu-Entry-7: BIR; Log out;http://live.boopsie.com/host/facebookfriends/?logout #fff#3b5998facebook #fff#6d84b4 97 friends (1 to 20 of 97) Aaron Levie|Box.net /USC / Silicon Valley, CA 3402659 3402659 Adam Fritzler|BitTorrent, Inc./ San Francisco, CA 545323645 545323645 Adriane Rose|RIT / CCRI 2441652924416529 Alex Feinberg|Santa Clara / Yahoo! / Silicon Valley, CA 73052437305243 Allan Pichler| 651958736 651958736 Andy Wick|Virginia Tech /Washington, DC 691927740 691927740 Ardy F.|Silicon Valley, CA 512018645512018645 Bahram Afshari|Silicon Valley, CA / Stanford 681147213681147213 Barbara Meier|Brown / Providence, RI 1013164 1013164 BradCleveland|Silicon Valley, CA 587478487 587478487 BradKay.Goodman|Boston, MA 713076764 713076764 Brian Greenberg|East Bay, CA593872292 593872292

The user might also desire to filter a large list of friends to locate adesired friend. For example, the user might enter a “d m” multi-prefixquery into search query field 1254 in FIG. 12F, the results of which canbe displayed by the client application in window 1252. The headinginformation 1258 is updated to reflect the filtered list of 4 friends,and only these 4 friend records 1256 are now displayed (in accordancewith the results received by client 118 and shown in Table 6).

If the user selects friend record 1266 shown in window 1262 in FIG. 12G,and invokes dynamic menu 1265 (for example, via menu item 1259 a in FIG.12F), the user might then elect, for example, to activate dynamic menuitem 1265 a to “message” that selected friend 1266 (via Facebook).

Upon activation of the “Message friend” dynamic menu item 1265 a, theclient application constructs the URI (from the Action field shown inTable 6), and passes it to browser 120 (including the “message”parameter containing the selected friend's user ID extracted from “field3” of the data shown in Table 6). In one embodiment, after “messaging”the selected friend, browser 120 may notify the user that the “message”was sent successfully and then (using the “.MOFI” technique discussedabove) automatically invoke the client application, which will “refresh”the user's list of friends. In another embodiment, the user will remainin the browser 120, but can still return manually to the clientapplication, which will be refreshed automatically.

Turning to Table 6, it can be seen that the “GET” request has changedonly slightly to reflect the search query (“c=d+m”) and to employ a“wwu” (instead of an “imenu”) command, which is a relatively minorimplementation decision. The dynamic menu HTTP headers have not changedin response to the user's query (though, in other embodiments, theycould be modified under control of server 128 to reflect a differentstate or context). Finally, the filtered set of results (4 “friend”records) are included for display by client 118, as shown in FIGS. 12Fand 12G.

TABLE 6 REQUEST (with filter “d m”) GET/wwu?c=d+m&u=http://live.boopsie.com/i/Facebook%20Friends/ HTTP/1.1UA-OS: WinCE (Smartphone) - Version (5.1); Carrier (none); Boopsie -Version (2.0.2.3) UA-pixels: 320x240 (9 lines) RESPONSE GET /listHTTP/1.1 Incremental-Search: on Content-Length: 305 B-MOFIID:2wl6n9pX5z4cV B-Action: skip-empty-links B-Progress: 1 to 4 of 4B-Menu-Entry-1: ION; Add to friends;http://live.boopsie.com/host/facebookfriends/?add=$4 B-Menu-Entry-2:ION; Poke friend; http://live.boopsie.com/host/facebookfriends/?poke=$3B-Menu-Entry-3: ION; Message friend;http://live.boopsie.com/host/facebookfriends/?message=$3 B-Menu-Entry-4:ION; Wall of friend;http://live.boopsie.com/host/facebookfriends/?wall=$2 B-Menu-Entry-5:BON; My profile; http://live.boopsie.com/host/facebookfriends/?profileB-Menu-Entry-6: BIS; Refresh B-Menu-Entry-7: BIR; Log out;http://live.boopsie.com/host/facebookfriends/?logout #fff#3b5998facebook #fff#6d84b4 4 friends Dan Manheim|Los Angeles, CA / UCLA /Threshold Marketing 596495304 596495304 Dave McNabola|Austin, TX / Duke1079384606 1079384606 Denis Ford|Seattle, WA / Microsoft 757528454757528454 Douglas Cheline|Thunderbird School of Global Management293500041 293500041

From the above descriptions of the various embodiments of theinteractive, multi-prefix, multi-tier and dynamic menu aspects of thepresent invention, many additional features and applications of thesetechniques will become apparent. For example, as noted above, thesetechniques could be incorporated wholly within a web browser (such asFirefox Mobile) or an integrated or standalone search engine (such asGoogle). One or more channels could be searchable, or simply selectedfrom a list of “smart bookmarks.” Moreover, a vertical web site or sites(such as Amazon, Wikipedia or IMDB) could provide various combinationsof these features as a standalone application containing one or morechannels.

Multiple channels could be searched at one time, particularly if theyare related, and dynamic menus could be employed to perform functionsand retrieve information from channels/web sites in advance of relyingupon a client web browser. Moreover, the interoperability between aclient application and a client web browser, as discussed above, greatlyenhances the user's experience by enabling the user to switch betweenthese applications when the particular context makes one or the othermore useful or desirable.

In a mobile communications environment, the advantages of interactivemulti-prefix queries, particularly when targeted across one or moretiers of channels, are quite significant. Avoiding multiple web pagerefreshes and links, providing results quickly and interactively andenabling users to minimize data entry is of great importance in such aresource-constrained environment. Moreover, adding contextualfunctionality such as dynamic menus that can vary among channels andeven individual records or program states (particularly when deployedusing a thin-client server-controlled architecture), significantlyenhances these advantages, by providing a high degree ofcontext-specific functionality while minimizing iterations amongresource-intensive steps such as following links or refreshing webpages.

Some portions of above description describe the embodiments in terms ofalgorithms and symbolic representations of operations on information.These algorithmic descriptions and representations are commonly used bythose skilled in the data processing arts to convey the substance oftheir work effectively to others skilled in the art. These operations,while described functionally, computationally or logically, areunderstood to be implemented by computer programs or equivalentelectrical circuits, microcode, or the like. Furthermore, it has alsoproven convenient at times, to refer to these arrangements of operationsas modules, without loss of generality. The described operations andtheir associated modules may be embodied in software, firmware,hardware, or any combinations thereof.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. It should be understood thatthese terms are not intended as synonyms for each other. For example,some embodiments may be described using the term “connected” to indicatethat two or more elements are in direct physical or electrical contactwith each other. In another example, some embodiments may be describedusing the term “coupled” to indicate that two or more elements are indirect physical or electrical contact. The term “coupled,” however, mayalso mean that two or more elements are not in direct contact with eachother, but yet still co-operate or interact with each other. Theembodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the invention. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for providing multi-prefix, interactive searchcapabilities on a mobile communications device through the disclosedprinciples herein. Thus, while particular embodiments and applicationshave been illustrated and described, it is to be understood that thedisclosed embodiments are not limited to the precise construction andcomponents disclosed herein. Various modifications, changes andvariations, which will be apparent to those skilled in the art, may bemade in the arrangement, operation and details of the method andapparatus disclosed herein without departing from the spirit and scopedefined in the appended claims.

1. An interactive information retrieval system, including non-transitorycomputer-accessible storage media, that searches a database of contentitems, the system comprising: a. a multi-prefix search module, embodiedin a first non-transitory computer-accessible storage medium, thatreceives keystrokes as they are entered by a user into a mobile device,searches for content items within the database that contain words havinga prefix matching the keystrokes, and generates a set of search resultscontaining matching content items; b. a search result delivery module,embodied in the first non-transitory computer-accessible storage medium,that delivers the set of search results to the mobile device for displayto the user; c. a client application, embodied in a secondnon-transitory computer-accessible storage medium, running on the mobiledevice that generates, based on the content of at least one of the setof search results, at least one user-selectable dynamic menu item thatis displayed as a screen object on a touchscreen of the mobile devicewith the set of search results, the user-selectable dynamic menu iteminvoking a built-in functionality of the mobile device when the userselects the user-selectable dynamic menu item, and d. wherein the clientapplication identifies one or more data fields within the content of atleast one of the set of search results, and the built-in functionalityof the mobile device invoked by the user-selectable dynamic menu itemreferences at least one of the data fields.
 2. The interactiveinformation retrieval system of claim 1, wherein the built-infunctionality of the mobile device that is invoked when the user selectsthe user-selectable dynamic menu item comprises placing a phone callusing the mobile device.
 3. The interactive information retrieval systemof claim 1, wherein the built-in functionality of the mobile device thatis invoked when the user selects the user-selectable dynamic menu itemcomprises sending a message using the mobile device.
 4. The interactiveinformation retrieval system of claim 3, wherein the message comprisesan email.
 5. The interactive information retrieval system of claim 3,wherein the message comprises a SMS message.
 6. The interactiveinformation retrieval system of claim 1, wherein the built-infunctionality of the mobile device that is invoked when the user selectsthe user-selectable dynamic menu item comprises determining directionsfrom a first location to a location identified in the one or more datafields.
 7. The interactive information retrieval system of claim 6,wherein the first location is a location of the mobile phone determinedusing a GPS locator.
 8. The interactive information retrieval system ofclaim 6, wherein the first location is a predefined location containedwithin a data filed of the mobile phone.
 9. The interactive informationretrieval system of claim 1, wherein the built-in functionality of themobile device that is invoked when the user selects the user-selectabledynamic menu item comprises obtaining a map of a desired area.
 10. Theinteractive information retrieval system of claim 1, wherein thebuilt-in functionality of the mobile device that is invoked when theuser selects the user-selectable dynamic menu item comprises displayinga customer review.
 11. The interactive information retrieval system ofclaim 1, wherein the built-in functionality of the mobile device that isinvoked when the user selects the user-selectable dynamic menu itemcomprises playing a video trailer.
 12. The interactive informationretrieval system of claim 1, wherein the client application is capableof distinguishing between a first method of selecting theuser-selectable dynamic menu item by the user and a second method ofselecting the user-selectable dynamic menu item by the user, the firstand second methods being different, and the built-in functionality ofthe mobile device invoked by the first and second methods referencedifferent data fields.
 13. The interactive information retrieval systemof claim 1, wherein the client application is capable of distinguishingbetween a first method of selecting the user-selectable dynamic menuitem by the user and a second method of selecting the user-selectabledynamic menu item by the user, the first and second methods beingdifferent, and the built-in functionality of the mobile device invokedby the first and second methods invoke different reference built-infunctionalities of the mobile device.
 14. The interactive informationretrieval system of claim 1, wherein the at least one user-selectabledynamic menu item is contained in a user selectable drop-down menu. 15.The interactive information retrieval system of claim 1, wherein theclient is capable of determining whether the user is logged into achannel on the mobile device, and the data field referenced by thebuilt-in functionality of the mobile device when the user is logged intothe channel is different than the data field referenced by the built-infunctionality of the mobile device when the user is not logged into thechannel.
 16. The interactive information retrieval system of claim 1,wherein the client is capable of determining whether the user is notlogged into a channel on the mobile device, and the user-selectabledynamic menu item generated by the client application when the user islogged into the channel is different than the user-selectable dynamicmenu item generated by the client application when the user is notlogged into the channel.